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Abstract 


The Guidance and Control Software (GCS) project was the 
last in a series of software reliability studies conducted at 
Langley Research Center between 1977 and 1994. The technical 
results of the GCS project were recorded after the experiment 
was completed. Some of the support documentation produced as 
part of the experiment, however, is serving an unexpected role 
far beyond its original project context. Some of the software used 
as part of the GCS project was developed to conform to the 
RTCA/DO-178B software standard, "Software Considerations in 
Airborne Systems and Equipment Certification, " used in the civil 
aviation industry. That standard requires extensive 
documentation throughout the software development life cycle, 
including plans, software requirements, design and source code, 
verification cases and results, and configuration management 
and quality control data. The project documentation that 
includes this information is open for public scrutiny without the 
legal or safety implications associated with comparable data 
from an avionics manufacturer. This public availability has 
afforded an opportunity to use the GCS project documents for 
DO-178B training. This report provides a brief overview of the 
GCS project, describes the 4-volume set of documents and the 
role they are playing in training, and includes the development 
documents from the GCS project. 


1 Introduction and Background on Software Error Studies 

As the pervasiveness of computer systems has increased, so has the desire and obligation to 
establish the reliability of these systems. Reliability estimation and prediction are standard 
activities in many engineering projects. For the software aspects of computer systems, however, 
reliability estimation and prediction have been topics of dispute, especially for safety-critical 
systems. A primary challenge is how to accurately model the failure behavior of software such 
that numerical estimates of reliability have sufficient credibility for systems where the probability 
of failure needs to be quite small, such as in commercial avionics systems (ref. 1). A second 
challenge is how to gather sufficient data to make such estimates. Software reliability models are 
not used in the civil aviation industry, for example, because “currently available methods do not 
provide results in which confidence can be placed to the level required for this purpose.” (ref. 2) 

In an effort to develop methods to credibly assess the reliability of software for safety-critical 
avionics applications, Langley Research Center initiated a Software Error Studies program in 
1977 (ref. 3). A major focus of those studies was on generating significant quantities of software 
failure data through controlled experimentation to better understand software failure processes. 
The intent of the Software Error Studies program was to incrementally increase complexity and 
realism in a series of experiments so that the final study would have statistically valid results, 
representative of actual software development processes. 

The Software Error Studies program started with initial investigations by the Aerospace 
Coiporation to define software reliability measures and data collection requirements (ref. 4-6). 



Next, Boeing Computer Services (BCS) and the Research Triangle Institute (RT1) conducted 
several simple software experiments with aerospace applications including missile tracking, 
launch interception, spline function interpolation, Earth satellite calculation, and pitch axis 
control (refs. 7-11). The experiment design used in these studies generally involved a number of 
programmers (denoted n) who independently generated computer code from a given specification 
of the problem to produce n versions of a program. In these experiments, no particular software 
development standards or life-cycle models were followed. Because the problems were relatively 
small and simple, the versions were compared to a known error-free version of the program to 
obtain information on software errors. 

Although the initial experiments were small and simplistic compared with real-world avionics 
development, they yielded some interesting results that have influenced software reliability 
modeling. The BCS and RT1 studies showed widely varying error rates for faults. This finding 
refuted a common assumption in early software reliability growth models that faults produced 
errors at equal rates. These studies also provided evidence of fault interaction where one fault 
could mask potentially erroneous behavior from another fault, or where two or more faults 
together cause errors when alone they would not. (ref. 12) Additional investigations with 77- 
version programs (ref. 13) found that points in the input space that cause an error can cluster and 
form “error crystals”. Extrapolating this finding to aerospace applications, where input signals 
tend to be continuous in nature, the error crystals may manifest themselves as clusters of 
successive faults that could have unintended consequences, (ref. 14) 

The last project in the Software Error Studies program was the Guidance and Control Software 
(GCS) project. It built on the previous experiments in two ways: (1) by requiring that the software 
specimens for the experiment be developed in compliance with current software development 
standards, and (2) by increasing the complexity of the application problem (ref. 15). At the time 
of the GCS project, the RTCA/DO-178B guidelines, "Software Considerations in Airborne 
Systems and Equipment Certification," (ref. 2) were the primary standard sanctioned by the 
Federal Aviation Administration (FAA) for developing software to be approved for use in 
commercial aircraft equipment (ref. 16). The DO-178B document describes objectives and 
design considerations to be used for the development of software as well as verification, 
configuration management, and quality assurance activities to be performed throughout the 
development process. The DO-178B guidelines were selected as the software development 
standard to be used for the GCS specimens. 

The software application selected for the GCS project, as the title indicates, is a guidance and 
control function for controlling the terminal descent trajectory of a planetary lander vehicle. This 
terminal descent trajectory is the same fundamental trajectory referred to as the “seven minutes of 
terror” in the entry, descent, and landing phase of a planetary mission, such as the recent Phoenix 
Mars Lander (ref. 17). For the GCS project, the software requirements were reverse engineered 
from a simulation program used to study the probability of success of the original NASA Viking 
Lander mission to Mars in the 1970s (ref. 18). It is important to emphasize that the software 
requirements documented for the GCS project, while realistic, are not the actual software 
requirements used for NASA’s Viking Lander or any other planetary landers. 

For the GCS experiment, two 1 teams of software engineers were each tasked to independently 
design, code, and verify a GCS program, following the software development guidance in DO- 
1786, as closely as possible. In addition to those teams, another GCS version was produced, 
without the constraint of compliance with DO-178B, to aid development and verification of the 
requirements and simulation environment. Once all versions were complete, data on residual 


1 The original plan for the GCS project called for three independent teams. Due to funding constraints, 
only two teams were able to complete the project. 
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errors was supposed to be collected by running all the versions simultaneously in a simulation 
environment, and using any discrepancies among the results of the versions as possible 
indications of errors. 

Results of the operational simulations and data collection are described in (ref. 15). The 
purpose of this report is not to repeat those results, but to disseminate some of the project 
documentation that has an unanticipated utility beyond its original project context. The project 
documentation of interest is the documentation developed by the teams required to comply with 
the DO-178B standard. That standard requires extensive records of all of the software 
development life cycle activities. For the GCS project, those records included 18 documents 
consisting of life cycle plans, development products including requirements and source code, 
verification cases and results, and configuration management and quality control data. 
Comparable data from a commercial avionics system would not be available for public review 
because of proprietary and other legal considerations. The GCS project documentation is not 
subject to those considerations because it is not data from an actual operational, or even 
prototype, system. But, the data has sufficient realism to provide a window into the types of 
activities and data involved in the production of DO-178 compliant software, which makes the 
GCS documentation desirable from a training perspective. 

The remainder of this report provides a brief overview of aspects of the GCS project relevant 
to using the documentation for training. This information includes a description of the GCS 
application, a synopsis of the software development processes used to follow the DO-178B 
guidance, and the data that was generated as a result. Because the complete set of compliance 
documents is large, the documents have been divided into four sets (planning, development, 
verification, and other integral process documents) contained in separate volumes of this report. 
Volume 2 includes in Appendices A-C the requirements, design, and source code generated as 
part of the development processes. 

2 Guidance and Control Software Application 

The requirements for the GCS application focus on two primary functions: (1) to provide 
guidance and engine control of the lander vehicle during its terminal phase of descent onto the 
planet's surface, and (2) to communicate sensory information to an orbiting platform about the 
vehicle and its descent. Figure 1 shows a sketch of the lander vehicle, taken from (ref. 18), noting 
the location of the terminal descent propulsion systems. 

The guidance package for the lander vehicle contains sensors that obtain information about the 
vehicle state and environment, a guidance and control computer, and actuators providing the 
thrust necessary for maintaining a safe descent. The vehicle has three accelerometers (one for 
each body axis), one Doppler radar with four beams, one altimeter radar, two temperature 
sensors, three strapped-down gyroscopes, three opposed pairs of roll engines, three axial thrust 
engines, one parachute release actuator, and a touch down sensor. The vehicle has a hexagonal, 
box-like shape; three legs and a surface sensing rod protrude from its undersurface. 

In general, the requirements for the planetary lander only concern the final descent to the 
surface. Figure 2 shows a sketch of the phases of the terminal descent trajectory. 
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After the lander has dropped from orbit, the software controls the engines of the vehicle to the 
surface of a planet. The initialization of the GCS starts the sensing of vehicle altitude. When a 
predefined engine ignition altitude is sensed by the altimeter radar, the GCS begins guidance and 
control of the lander. The axial and roll engines are ignited; while the axial engines are warming 
up, the parachute remains connected to the vehicle. During this engine warm-up phase, the 
aerodynamics of the parachute dictate the vehicle’s trajectory. Vehicle attitude is maintained by 
firing the engines in a throttled-down condition. Once the main engines become hot, the 
parachute is released and the GCS performs an attitude correction maneuver and then follows a 
controlled acceleration descent until a predetermined velocity-altitude contour is crossed. The 
GCS then attempts to maintain the descent of the lander along this predetermined velocity- 
altitude contour. The lander descends along this contour until a predefined engine shut off 
altitude is reached or touchdown is sensed. After all engines are shut off, the lander free-falls to 
the surface. 

The software requirements for this guidance and control application are contained in a 
document called the Guidance and Control Development Specification (in Volume 2). As 
mentioned earlier, the initial requirements for this application were reverse engineered from a 
simulation program used to study the probability of success of the original NASA Viking Lander 
mission to Mars. Prior to use in the experiment, the requirements were revised to make them 
suitable for use in an //-version software experiment. Each of the GCS programs for the 
experiment were developed from the same requirements document. 

3 Software Life Cycle Processes and Documentation 

Having some of the project teams adhere to the DO-178B guidelines as they created a software 
version for the experiment was a significant element of the GCS project, requiring the 
development and tracking of numerous software engineering artifacts not normally associated 
with a software engineering experiment. The purpose of DO-178B is to provide guidelines for 
the production of software such that the completed implementation performs its intended function 
with a level of confidence in safety satisfactory for airworthiness. Along with the production of 
software is the generation of an extensive set of documents recording the production activities. 

DO-178B defines software development activities and objectives for the development life 
cycle of the software, and the evidence that is needed to show compliance. The life-cycle 
processes are divided into planning, development, and integral processes. The planning process 
defines and coordinates the software development processes and the integral processes. The 
software development processes involve identification of software requirements, software design 
and coding, and integration; that is, the development processes directly result in the software 
product. Finally, the integral processes function throughout the software development processes 
to ensure integrity of the software products. The integral processes include software verification, 
configuration management, and quality assurance processes. Section 11 of DO-178B describes 
data that should be produced as evidence of performing all of the life cycle process activities. 

For the GCS project, some of this data was common for all of the teams, and other data was 
intended to be specific to each team. For example, each team worked with the same plans, 
standards, and requirements. Then, each individual team was responsible for independently 
developing their own design, code, and corresponding verification data. To distinguish the 
versions, each team was assigned a planetary name: Mercury, Venus, and Pluto 2 . 


1 At the time the GCS experiment was conducted, Pluto had not yet been relegated to non-planet status. 
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Table 1. Life Cycle Data 


Planning Process 
Documents 

• Plan for Software Aspects of 
Certification 

• Software Development Plan 

• Software Verification Plan 

• Software Configuration 
Management Pian 

• Software Qiiaiity Assurance 
Pian 

• Software Requirements 
Standards 

• Software Design Standards 

• Software Code Standards 


Integral Process 
Documents 

• Software Verification Cases 
and Procedures 

• Software Verification Resuits 

• Software Life Cycie 
Environment Configuration 
Index 

• Software Configuration 
Index 

• Probiem Reports 

• Software Configuration 
Management Records 

• Software Quaiity Assurance 
Records 

• Software Accompiishment 
Summary 


Development Process 
Documents 

• Software Requirements Data 

• Design Description 

• Source Code 

• Executable Object Code 


The DO-178B data associated with the development of the Pluto version of the GCS was 
selected for publication. For dissemination purposes, the Pluto data was divided into the 
following 4 subsets: 

Volume 1: Planning Documents 

• Plan for Software Aspects of Certification of the Guidance and Control Software Project 

• Software Configuration Management Plan for the Guidance and Control Software Project 

• Software Quality Assurance Plan for the Guidance and Control Software Project 

• Software Verification Plan for the Guidance and Control Software Project 

• Software Development Standards for the Guidance and Control Software Project 

Volume 2: Development Documents 

• Guidance and Control Software Development Specification 

• Design Description for the Pluto Implementation of the Guidance and Control Software 

• Source Code for the Pluto Implementation of the Guidance and Control Software 

Volume 3: Verification Documents 

• Software Verification Cases and Procedures for the Guidance and Control Software Project 

• Software Verification Results for the Pluto Implementation of GCS 

• Review Records for the Pluto Implementation of the Guidance and Control Software 

• Test Results Logs for the Pluto Implementation of the Guidance and Control Software 
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Volume 4: Other Integral Processes Documents 

• Software Accomplishment Summary for the Guidance and Control Software Project 

• Software Configuration Index for the Guidance and Control Software Project 

• Problem Reports for the Pluto Implementation of the Guidance and Control Software 

• Support Documentation Change Reports for the Guidance and Control Software Project 

• Configuration Management Records for the Guidance and Control Software Project 

• Software Quality Assurance Records for the Guidance and Control Software Project 

Appendices A-C contain the original development documents for the GCS project. The 
Guidance and Control Software Development Specification, in Appendix A, contains all of the 
high-level requirements for the guidance and control application, as well as instructions for 
interfacing with the experiment’s simulator.. The low-level requirements and architecture are 
contained in the Design Description for the Pluto Implementation of the Guidance and Control 
Software in Appendix B. The design was developed using a structured analysis tool called 
Teamwork from Cadre Technologies. Finally, Appendix C contains the Source Code for the 
Pluto Implementation of the Guidance and Control Software with the Fortran source code for the 
Pluto implementation. 

The content of the documents in the appendices has not been altered from the original versions 
produced during the project. 

4 Role in Training 

At the time of the GCS project, there was no publicly available information, such as templates, 
or examples, or training courses, to help a novice developer generate the type of evidence that a 
certificating authority would expect to see to demonstrate compliance with DO-178B. As 
mentioned earlier, compliance data from a real avionics system is not typically available for 
public review because of various legal and safety considerations. For example, an avionics 
manufacturer would likely consider the design and implementation of a system to be proprietary. 
Those considerations do not apply to the data from the GCS project, because neither the 
requirements nor the software versions represent an actual system with safety, liability, or other 
considerations. 

In addition to the availability of data, the GCS requirements and DO-178B compliance data 
are sufficiently realistic to serve as an example of a DO-178B project: one that is small enough in 
scale to be studied in a training course. The GCS documentation provides a window into the 
activities and data produced throughout the development life cycle to comply with DO-178B. 
Because the Federal Aviation Administration (FAA) was aware of the GCS project, they 
recognized the potential value of the documentation for training. The FAA has designed software 
training to include a case study portion that addresses avionics software issues that arise from the 
application of the DO-178B guidelines. The case study gives students the opportunity to use 
auditing techniques to identify flaws in lifecycle data. Because the GCS data was produced by 
novices, there are plenty of flaws to find. 

5 Summary 

From 1977-1994, NASA Langley Research Center conducted a Software Error Studies 
program that generated data that provided insights into the software failure process and into 
conducting software engineering experiments as well. The GCS project was the final experiment 
in that program. A unique feature of the GCS project was the requirement for some of the 
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software specimens used in the experiment to conform to the RTCA/DO-178B software standard, 
"Software Considerations in Airborne Systems and Equipment Certification," used in the civil 
aviation industry. The project documentation produced to meet that requirement has had the 
unanticipated benefit of serving as case study material in software certification training long after 
the conclusion of the original experiment. Volume 2 of this report contains all of the 
development artifacts from the GCS project.: requirements, design, and source code Other 
volumes of this report contain the rest of the GCS compliance data including planning, 
verification, and configuration management and quality assurance documents. 
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A. FOREWORD 


This specification defines a guidance and control system for a planetary landing vehicle during 
its terminal phase of descent. It is written for an experienced programmer with two or more years 
of full-time industrial programming experience using a scientific programming language. The 
programmer should have an adequate background, either through college courses or job training 
in mathematics, physics, differential equations, and numerical integration. The specification was 
written with the assumption that the implementation would be coded in FORTRAN; however, 
other languages can be used. 
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A.l INTRODUCTION 


PURPOSE OF THE GUIDANCE AND CONTROL SOFTWARE 

The Guidance and Control Software (GCS) represents the Viking lander (ref. A.20) on- 
board navigational software. The purpose of this software is to: 

1 . provide guidance and engine control of the vehicle (shown in Figure A. 1 . 1 ) during its 
terminal phase of descent onto a surface and 

2. communicate sensory information about the vehicle and its descent to some other 
receiving device. 

A typical descent trajectory is shown in Figure A. 1.2. 

The initialization of the GCS starts the sensing of vehicle altitude. When a 
predefined engine ignition altitude is sensed by the altimeter radar, the GCS begins 
guidance and control of the vehicle. The axial engines are ignited; while the axial 
engines are warming up, the parachute remains connected to the vehicle. During this 
engine wann-up phase, the aerodynamics of the parachute dictate the trajectory followed 
by the vehicle. Vehicle attitude is maintained by firing the engines in a throttled-down 
condition. Once the main engines become hot, the parachute is released and the GCS 
performs an attitude correction maneuver and then follows a controlled acceleration 
descent until a predetermined velocity-altitude contour is crossed (see Figure A. 5. 1). The 
GCS then attempts to maintain the descent of the vehicle along this predetermined 
velocity-altitude contour. The vehicle descends along this contour until a predefined 
engine shut off altitude is reached or touchdown is sensed. After all engines are shut off, 
the vehicle free-falls to the surface. 

VEHICLE CONFIGURATION 

The vehicle to be controlled is a guidance package containing sensors which obtain 
information about the vehicle state, a guidance and control computer, and actuators 
providing the thrust necessary for maintaining a safe descent. The vehicle has three 
accelerometers (one for each body axis), one doppler radar with four beams, one 
altimeter radar, two temperature sensors, three strapped-down gyroscopes, three opposed 
pairs of roll engines, three axial thrust engines, one parachute release actuator, and a 
touch down sensor. The vehicle has a hexagonal, box-like shape with three legs and a 
surface sensing rod protruding from its undersurface. 
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Figure A. 1.2 A TYPICAL TERMINAL DESCENT TRAJECTORY 



Phase 5 


TERMINAL DESCENT 

Prior to the terminal descent phase, the vehicle falls with a parachute attached. This 
parachute is released seconds after the engines ignite, and terminal descent begins. 
During tenninal descent, the vehicle follows a modified gravity-turn guidance law until a 
predetermined altitude is reached. The atmosphere introduces drag forces, including the 
random effects of wind. Independently throttled engines slow the vehicle down. These 
engines can control the vehicle's orientation, and roll engines control the vehicle’s roll 
rate. Roll control is necessary to keep the doppler radars in lock and insure that the 
desired touch down attitude (land on two legs prior to the third) is maintained. 

The velocity during descent follows the predetermined velocity-altitude contour. At 
a specific altitude above the planet surface, the vehicle is maintained at a constant descent 
velocity. Once the surface is sensed, all engines are shut down and the vehicle free falls 
to the surface. 

VEHICLE DYNAMICS 

Frames of Reference 

Terminal descent is described in terms of two coordinate systems: 

1 . the surface-oriented coordinate system, and 

2. the vehicle-oriented coordinate system. 

In the surface coordinate system, the z p axis is viewed as nonnal to the surface and 
points down as shown in Figure A. 1.2. The x p axis points north, and the y p points east. 

By defining a unit vector as a vector of length equal to one unit along each axis in 
both the planetary and vehicular frames of reference, a relation between these two frames 
of reference may be established. Any vector can then be defined as a multiple of the unit 
vector along each of the axes defined in the frame of reference. Thus, the velocity of the 
vehicle V may be defined in the vehicle’s frame of reference as: v x J v + v y J v + V, k v , where 

Wv> and K are the unit vectors in the x, y, and z directions of the vehicles coordinate 

system (unit vectors are usually represented by lower case i, j, or k with a hat to show 
that they are unit vectors). V x , V v , and V z represent the components of the vehicle 

velocity in the given direction. At the same time, the velocity of the vehicle may be 
described in the planetary coordinate system as: V x i p +V y j p + V : k p , where the 

subscript p represents planetary rather than vehicle coordinates. Note, since the two 
coordinate systems are not oriented in the same direction, the values of V x will not be 
equal to V Xp , but the magnitude of the total vector V will be the same in both systems. 
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Also the difference in the magnitudes of individual components represents the difference 
in relative orientation between the two coordinate systems. 

The dot product ( a-b ) is defined as the magnitude of a multiplied by the 

magnitude of b and then by the cosine of the angle between the vectors, 


a-b = |«||ft|cosZni 


The dot product is used to project a onto b and can be used to project a vector in 
one frame of reference onto another one. Rather than calculate the needed cosines each 
time a vector must be transformed from one frame of reference into another, the cosines 
of the angles between each unit vector of the vehicular and planetary coordinate systems 
are computed and placed into a direction cosine matrix. This matrix is then used along 
with the vector's magnitude in each dimension of the original frame of reference to 
compute a dot product. This product gives the vector's magnitude in each dimension of 
the new frame of reference. 

The transfonnation between the vehicle and the surface coordinate systems at time t 
is specified by a matrix of direction cosines, 
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where d(i,j ) denotes the angle between vectors * and j , etc. 

The change in orientation of the vehicle during descent makes the update of the 
direction cosine matrix necessary at each time step. This update is specified in the 
following equation: 
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where the matrix containing the p v , q v , and r v tenns is the rate of rotation about the axes 
of the vehicle which may be obtained from sensor values. 

Linear Velocity 

The linear components of velocity for the vehicle during terminal descent are 
denoted by x v , T v > and A in the vehicle coordinate system and by x p ,y p , and z p in the 
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surface coordinate system, where the dot (’) notation indicates derivatives with respect to 
time. 

Vehicle Position 

Vehicle position is expressed in terms of the surface coordinate system by 
transforming change in position (velocity) in the vehicle coordinate system into change in 
position in the surface frame and integrating as follows: 


f ■ \ 


(h 




( • ^ 

Xp 1 


m ! 

«i 1 


f 

y p 

= 

k 

m 2 

n 2 


Tv 

y Z P) 

t 

1/3 

m 3 

n 3 J 

t 

u. 


and 


f \ 


( ■ 5 


x„ 1 




P 


p 


y p 

=1 

y P 

dr 

Z i 




V pJ 

t 

K pJ 



Angular Velocity 

Roll, pitch, and yaw angular velocities are represented by the quantities p v , q v , and 
r v in the vehicle frame of reference only. Roll is about the x v axis, pitch is about the y v 
axis, and yaw is about the z v axis, as shown in Figure A. 1.3. A more in-depth 
explanation of angular velocity naming conventions and other related material may be 
found in section II, part B of Reference (ref. A. 3). 

Vehicle Attitude 

The vehicle attitude at time t is a function of the vehicle attitude (known by 
reference to celestial objects) at the start of descent at time to and the cumulative changes 
in attitude from time to to time t . 

Acceleration 

The linear components of acceleration for the vehicle in the vehicle frame of 
reference during tenninal descent are denoted by x v , y v , and respectively. 

Further Reading 

The subjects of vector mathematics, transfonnations between frames of references, 
vector calculus, and rotating coordinate systems may not be sufficiently covered here for 
the user; however, such depth is not intended for this document. Chapter 4 of Classical 
Mechanics (ref. A.4) contains a detailed explanation of rigid body motion and 
transformation of vectors into multiple frames of reference or coordinate systems. 
Chapters 15 and 16 of Engineering Mechanics (ref. A. 5) contains a more basic approach 
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to the same ideas of multiple frames of reference and vector mechanics. Chapter 14 of 
(ref. A.6) and Chapter 5 of (ref. A. 7) also discuss rotational motion and multiple frames 
of reference, as well as vector mechanics and calculus. Two other books of possible 
interest are (ref. A. 8) and (ref. A. 9). Both cover the mechanics of particles and dynamics, 
with strong references to particle trajectories and rocket dynamics. Also, these texts are 
basic in nature and require only a rudimentary knowledge of physics, math, or 
engineering. 
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VEHICLE GUIDANCE 

Vehicle guidance is accomplished by varying the engine thrust so that the vehicle 
follows a single predetermined velocity-altitude contour. This contour is made available 
during GCS initialization. Applying too great a deceleration early in the descent brings 
the vehicle velocity to its tenninal value too high above the surface, resulting in 
insufficient propellant for final descent. Applying too small a thrust lets the vehicle 
impact the surface with too great a velocity. Either condition could be disastrous. As 
soon as the touch down sensor touches the surface, the engines are shut off. 
Approximately ninety percent of propellant or thrust is used to minimize gravity losses; 
the remaining ten percent is used for steering. 

A gravity-tum steering law is mechanized by rotating the vehicle in pitch and yaw 
until the body's lateral axis velocities are zero (causing the thrust axis to point along the 
total velocity vector). The action of gravity causes the thrust axis to rotate toward the 
vertical as the total velocity is reduced. An arbitrary roll orientation is maintained with 
an attitude hold mode during the descent. 

ENGINES 

The vehicle has three axial engines that supply the force necessary to slow the 
vehicle and allow it to safely land. Roll is controlled by three pairs of roll engines on the 
lander supplying rotational thrust. Figure A. 1.3 shows the axial and roll engines and the 
resulting thrust forces they impart to the vehicle. 

Axial Engine (Thrust) Control 

Three thrust engines first orient the vehicle so that their combined thrust vector 
opposes the vehicle's velocity vector. Thrust (axial direction) engine control is a function 
of pitch error, yaw error, thrust error, and deviation from the velocity-altitude contour. A 
combination of proportional and integral control (PI) logic is applied to pitch and yaw 
control. The integral portion helps to reduce the steady-state pitch and yaw error. 

If no thrust error or velocity-altitude contour deviation occurs, then axial engine 
response provides only pitch and yaw control via the PI control law. Use of this control 
law implies that the overshoot problem for pitch-yaw control is probably small. 

Thrust control is implemented by a proportional-integral-derivative (PID) control 
law. The derivative control added here damps out overshoot. 

Roll Engine Control 

Roll control is attained by pulsing the three pairs of roll engines and is a function of 
roll angle deviation and roll rate (p v ) about the x axis. Roll engine specific impulse and 
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thrust per unit time are constant with the integrated thrust controlled by pulse rate. Angle 
deviations are controlled within a very small range of 0.25 to 0.35 degrees. 


GENERAL INFORMATION 

NOTATION 

Matrices and Arrays 

It should be noted that throughout this specification, the words matrix and array are 
often interchanged. No significance should be placed upon the use of one word as 
opposed to use of the other. 

All matrices are referenced with the row index first and the column index second. In 
the cases where there is a time history (see definition of history variable below), the last 
index is the time index. 

When the name of an array which contains a time history is given without any index 
for the time history being specified, the most recent value is implied. 

Operators 

Throughout this specification, matrix operations (particularly multiplication) are 
required, and on some occasions, non-standard operations are used upon matrices. The 
following symbols are used to denote the types of multiplication to be applied. 


Dots (•) Small dots are used to denote scalar multiplication. For example: 

3-4 =12 

Multiplication sign (x) This symbol is used to denote standard matrix multiplication. 
This does NOT imply a cross product, nor strictly a dot product. The definition of 
this type of operation is given below: 

Ax B= C 

where 

Vi and Vj , C y = ^ A lk ■ B kj 

VA 


Asterisks (*) Asterisks are used in conjunction with index markers to show that the 
operations are to be conducted on individual elements of arrays or vectors as if they 
were scalars. This is often the case when calculating sensor values or other similar 
functions when multiple scalars are grouped together for convenience. For example, 
the following equation is listed in ASP: 
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A _ ACCELERATION _ M(i)= A_BIAS(i) + A_ GAINii ) * A_ COUNTER (i) 

where i ranges from 1 to 3 and represents the three directions x, y, and z. In 
this case, the first element of AACCELERATIONM would be calculated 
as follows: 

A ACCELERATION _ M( 1) = A_ BIAS{ 1)+ A_ GAIN{\)- A_ COUNTERS) 

No Operator In those cases where variables, matrices, or scalars are located directly 
beside each other with no operator between, standard multiplication is implied. 

Thus two matrices collocated would be multiplied as if they had the x operator 
between them, while two scalars would be multiplied as if they had the ' operator 
between them. Also, if a scalar and a matrix (of one or more dimensions) were 
collocated, then the scalar would be multiplied by each element of the matrix and a 
new matrix of equal dimensions would be generated. 

DEFINITIONS 

Implementation 

Computer code which fulfills all of the requirements outlined in the GCS 
Development Specification. 

Functional Unit 

Section A. 5 is divided into eleven subsections, each of which describes the 
requirements for a particular function to be performed by the GCS software. Throughout 
this specification, the term "functional unit" will be used to refer to one of these eleven 
functions. Note that there is not necessarily a one-to-one correspondence between a 
"functional unit" and a distinct unit or module of software code in an implementation. 

Frame 

A frame is the length of time necessary to execute all scheduled functional units. 
Each frame has two different time values associated with it. The first is the actual c.p.u. 
time that it takes to execute the GCS software on the simulation host computer, while the 
second is the allotted time for a frame on the actual lander. The global variable 
DELTAT represents the time for one frame on the actual lander and is needed in the 
GCS code for the integration of the dynamic equations for the lander. 
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Subframe 

A subframe is one of the three individual units of time which together make up a 
frame. The three subframes are named the Sensor Processing subframe (subframe 1), the 
Guidance Processing subframe (subframe 2), and the Control Law Processing subframe 
(subframe 3). In each frame, subframe 1 is executed first, subframe 2 is executed second, 
and subframe 3 is the last subframe executed. 

Data Store 

The definition for a data or control store given in Hatley (ref. A. 13) is "A data or 
control store is simply a data or control flow frozen in time. The data or control 
information it contains may be used any time after that information is stored and in any 
order." In this specification, all stores contain data, while some also contain data 
conditions. For the purposes of this specification, the term "data store" will be used to 
refer to any store which contains some combination of data and data conditions. Thus, all 
four stores listed in the Data Requirements Dictionary part 11 will be referred to as "data 
stores". 

Global Data Store Variable 

A global data store variable is any variable listed in any of the four global data 
stores in Section A. 6, namely GU1DANCE_STATE data store (Table A. 6.1), 
EXTERNAL data store (Table A.6.2), SENSOR_OUTPUT data store (Table A.6.3), or 
RUN_PARAMETERS data store (Table A.6.4). 

History Variable 

Within this specification, a particular array, hereafter referred to as a "history 
variable" is one which contains a time history dimension; that is, it contains values for the 
current frame as well as for previous frames. The history variables are the following: 

AACCELERATION (1:3,0:4) 

A STATUS (1:3, 0:3) 

ARALTITUDE (0:4) 

ARSTATUS (0:4) 

G ROTATION (1:3, 0:4) 

GPALTITUDE (0:4) 

GP ATTITUDE (1:3, 1:3, 0:4) 

GP_ VELOCITY (1:3, 0:4) 

K ALT (0:4) 

K MATRIX (1:3, 1:3, 0:4) 

TDLR VELOCITY (1:3, 0:4) 

In each case, the last dimension is the time dimension. The first subscript in a time 
history dimension is always declared to be zero. The time dimension contains a set of 
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scalars, vectors, or arrays, depending on whether the total number of dimensions is one, 
two, or three, respectively. Let the term "object" denote a scalar, vector, or array, as 
appropriate for the particular variable. Each of these variables contains either four or five 
objects, depending on whether the last dimension is declared to be 0:3 or 0:4 respectively. 
The variable ASTATUS contains four objects, while each of the other time history 
variables contains five objects. 

Each of the variables listed contains a most recent object and either three or four 
previous objects. The object with a time subscript of zero is the most recent object; the 
object with a time subscript of one is the object which is one frame older; the object with 
a time subscript of two is the object which is two frames older, etc.; the object with the 
largest time subscript (three or four) is the oldest object. 

CONVENTIONS 
FORTRAN Convention 

This specification was written with the assumption that the implementation would 
be coded in FORTRAN. If the development language used is something other than 
FORTRAN, the programmer must investigate the possibility of differences between 
FORTRAN and the development language chosen. 

REQUIREMENTS 
Order of Processing 

Within each functional unit in Chapter 5, the processing steps are given in a 
particular order. If the implementation uses the same order as that given in the 
specification, then correct results should be obtained; however, the programmer is free to 
use a different order as long as the change in order does not affect the outputs. 

Calls to GCSSIMRENDEZVOUS 

There must be a call to GCS SIM RENDEZVOUS prior to the execution of each 
subframe. See section A. 2 and section A. 8 for discussions regarding 
GCSSIMRENDEZVOUS. 

Control Signals 

The control signals listed in Table A. 6. 5 in Part III of the Data Requirements 
Dictionary may be implemented by the programmer in any fonn desired, or they may be 
completely ignored and the control of the program may be conducted through other 
means. 
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Number Representations 

When variables are given in sign-magnitude or other unusual formats, conversion or 
manipulation may be necessary. 

Conversion of Units 

It is the responsibility of the programmer to be sure that any implied conversion of 
units is perfonned. 

Global Data Store Organization 

Part II of the Data Requirements Dictionary contains descriptions of four required 
data stores. Each of these data stores is to be located in a separate, globally accessible 
data region. The division of the global data stores into four separate regions illustrates 
the fact these regions have a direct mapping to a specific implementation of GCS on 
hardware components of an actual lander. (See Figure A.B.l). 

If the implementation is being written in FORTRAN, four labeled common blocks 
should be declared with the labels GUIDANCESTATE, EXTERNAL, 
SENSOR OUTPUT, and RUN_P ARAMETERS , respectively (See Tables 6.1, 6.2, 6.3, 
and 6.4). The variables declared in each labeled common block must be in the same 
order as those in the corresponding table. 

Use of Variables That Are Not in the Global Data Stores 

A programmer may use variables in addition to the global data store variables; 
however, if the value of such a variable is dependent upon the values of any global data 
store variable(s), then the programmer should only use the value of such a variable in the 
same subframe of the same frame in which it was calculated. 

Use of Tables 

Some tables have the heading "CURRENT STATE" and "ACTIONS". If the actual 
state of the variables appears under the "CURRENT STATE" section in the table, then 
the actions listed in the same line are to be performed. If the actions in one line of the 
table are perfonned, then none of the actions in any other line of the table should be 
perfonned in the same subframe. If the actual cunent state is not represented in any line 
under the "CURRENT STATE" section of the table, then no action is to be taken. 

Rotation of History Variables 

In Chapter 5, in certain functional units, an instruction is given to "rotate" specific 
variables. Table A. 1.1 illustrates what is meant by rotation. The table is given for a 
variable with a time dimension of 0:4. For a variable with a time dimension of 0:3, the 
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last line of the table should be ignored. Note that after the variable has been rotated, the 
new or current object is calculated and placed into the zeroth time history position. 


Table A. 1.1 ROTATION OF VARIABLES 


TIME HISTORY 
SUBSCRIPT 

VALUES BEFORE 
ROTATION 

VALUES AFTER 
ROTATION 

VALUE AFTER 
CALCULATIONS 
FOR CURRENT 
FRAME 

0 

O n -l 

X 

O n 

1 

O n -2 

O n -l 

O n -l 

2 

O n -3 

O n -2 

O n -2 

3 

On-4 

O n -3 

O n -3 

4 

On-5 

On-4 

On-4 


Note: O; denotes object that was calculated in frame i 
n = current frame number 
X = denotes that any value is acceptable 


Precision 

All calculations involving floating point variables should be done with precision 
equivalent to that of FORTRAN D-floating (REAL*8). 

EXCEPTION HANDLING 

During the execution of a computer program, exception conditions may 
sometimes occur. The implementation should anticipate or detect certain types of 
exception conditions and take specific actions. The relevant exception conditions and the 
actions to be taken are listed below. 

Exception Conditions 

DIVIDE BY ZERO 

A division is performed, but the divisor is equal to zero. 

NEGATIVE SQUARE ROOT 

A square root is taken, but the argument for the square root is negative. 

UPPER OR LOWER LIMIT EXCEEDED 

The current value for a data element exceeds its upper or lower limit as specified in the 
range section in the Data Requirements Dictionary Part 1. 
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Only certain data elements under certain conditions are to be checked for limits exceeded. 
The criteria for which elements are to be checked, in what context they are to be checked, 
and when they must be checked is as follows: 

Which data elements: 

A particular data element is to be checked for limits exceeded only if it is of data type 
REAL*8, and is in either of the two global data stores GUIDANCESTATE or 
SENSOROUTPUT. 

Context for check: 

A data element is to be checked only when it is being used as an input. Rotation of a 
data element is not considered to be a use as an input for the purposes of limit 
checking. If the data element is a vector or array, then each element in the vector or 
array that is being used as input must be checked, including history values. It is not 
necessary for the functional unit CP to check any of its input data elements for limit 
exceeded. 

When data element must be checked: 

When an input data element is to be used or processed in a given subframe, then it 
must be checked sometime within that same subframe before it is used. If the data 
element is also being updated or changed in the same subframe before it is being used 
as an input, then it must be checked sometime between the time it is updated and the 
time it is used. 


Action to be Taken for Each Specified Exception Condition 

Write the appropriate output as specified below to the FORTRAN Logical Unit 
Number 6 and then continue. In the case of UPPER/LOWER LIMIT EXCEEDED, do 
not modify the data element. Note that to "continue" implies that the divide will be 
executed, or the square root will be taken, or the data element with exceeded limit will be 
used. 


Output to be Generated for Each Exception Condition 

The first line of the exception message should appear as follows: 

" %EXCEPTI0NAL-C0NDIT10N-GCS-"<insert specific condition here> 
where the specific condition is one of the following: 
"DIVIDEBYZERO" 

"NEGATIVESQUAREROOT" 

"LOWERLIMITEXCEEDED" 

"UPPER LIMIT EXCEEDED" 


The second line of the exception message should contain the name of the functional 
unit where the exception condition occurred (i.e. AECLP, ASP, etc.), the name of the 
actual subroutine where the exception condition occurred, and the current value of the 
frame counter. Implementations that are coded in FORTRAN should use the following 
FORTRAN format statement: 
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FORMAT (x, a6, x, a32, x, i4) 

A third line of the exception message containing information that is specific to the 

individual error type may be required as specified below. 

Divide By Zero 

No additional output necessary. 


Negative Square Root 

Display the value of the argument to the square root operation. 
Use FORTRAN format statement FORMAT (x, e23.14). 


Lower Limit Exceeded 

Display the name of the data element in question and the value of the data element. 
Use FORTRAN format statement FORMAT (x, a32, e23. 14) for type real elements. 

Upper Limit Exceeded 

Display the name of the data element in question and the value of the data element. 
Use FORTRAN format statement FORMAT (x, a32, e23. 14) for type real elements. 


A.2 LEVELS 0 AND 1 SPECIFICATION 

LEVEL 0 SPECIFICATION 


The GCS will provide an interface between the sensors (rate of descent, attitude, 
etc.) and the engines (roll and axial). The purpose of the GCS is to keep the vehicle 
descending along the predetermined velocity-altitude contour which has been chosen to 
conserve enough fuel to effect a safe attitude and touch down. 

The GCS effects this control by: 

• processing the following sensor information: 

acceleration data from the three accelerometers — one for each vehicle axis, 
range rate data from four splayed doppler radar beams, 
altitude data from one altimeter radar, 

temperature data from a solid-state temperature sensor and a thermocouple pair 
temperature sensor, 

rates of rotation from three strapped-down gyroscopes — one for each vehicle axis, and 
sensing of touch down by the touch down sensor. 
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• determining the appropriate commands for the axial and roll engines and the chute release 
mechanism and issuing them to keep the vehicle on a predetermined velocity-altitude contour. 

The GCS also transmits telemetry data and synchronizes through a rendezvous 
routine (GCS SIM RENDEZVOUS) with GCS SIM (ref. A. 10), the simulator and 
controller. 

Note that implementations of the GCS developed from this specification may be 
executed singly or in parallel. Consequently, only specific system services can be used in 
an implementation. In particular, a rendezvous routine will be provided and should be 
invoked, as specified in the implementation notes in section A. 8. In addition, FORTRAN 
Intrinsic Functions may be used. Other system services and library routines are explicitly 
excluded from use by the programmer. 

Figures 2.2 through 2.5, 3.1, 3.2, and 4.1 through 4.4, and Tables 2.1, 3.1, 4.1, and 
4.2 follow Hatley's extension to Structured Analysis (see section A. 7), with the following 
exceptions and assumptions. 

Exceptions: 

1. Any data store may appear at more than one level because the processes 
specified do not communicate directly but only through data stores. 

2. Any unlabeled flow between a process and a data store may not necessarily 
carry all the information in the data store (the actual flow content is defined 
by the process specification and the Data Requirements Dictionary Part II). 

Assumptions: 

1. The initial value for control signals is assumed to be "FALSE". 

2. In a process activation table (PAT), an empty process cell indicates the 
process is deactivated. 

3. In a PAT, an empty output cell indicates the control signal value remains 
unchanged. 

4. In a PAT, output control signals receive values before any processes are 
activated and therefore may delay the activation of processes by deactivating 
their parent process. 
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An example of assumption 4 is Table A. 3.1 where setting RENDEZVOUS to 
"TRUE" delays the activation of the processes of which RUNGCS is composed until 
GCS SIM sets RENDEZVOUS to "FALSE". 
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Figure A.2.2 DATA CONTEXT DIAGRAM: LANDER 
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Figure A.2.3 CONTROL CONTEXT DIAGRAM: LANDER 
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LEVEL 1 SPECIFICATION 


Figure A2A DATA FLOW DIAGRAM (DFD) 0: GCS 
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Figure A.2.5 CONTROL FLOW DIAGRAM (CFD) 0: GCS 



RENDEZVOUS is only set to "TRUE" by RUN_GCS and it is only set to "FALSE" 
by GCSSIM. 
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Table A.2.1 CONTROL SPECIFICATION (C-SPEC) 0: GCS 



"INITGCS" 

"RUNGCS" 

-RENDEZVOUS & -RUNDONE 


1 

RENDEZVOUS & -INITDONE & -RUN DONE 

1 


(RENDEZVOUS & INIT DONE) | RUN DONE 
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A.3 LEVEL 2 SPECIFICATIONprocess specification (P-Spec) i: 

INITGCS 

PURPOSE INIT GCS initializes the guidance and control software. 

INPUT 

IN IT 1 AL1Z AT IOND AT A 

OUTPUT 

I INITIALIZATION DATA I 


PROCESS INIT GCS is actually a part of GCS SIM RENDEZVOUS, which will be supplied 
to the programmer; thus the functions performed by INIT GCS are listed here for information 
only, but are not the responsibility of the programmer. There should be a call to 
GCS SIM RENDEZVOUS, prior to executing each subframe. The first call to 
GCS SIM RENDEZVOUS will cause INIT GCS to automatically be executed. INIT GCS will 
initialize all variables in the group flow INITIALIZATIONDATA, which is defined in Table 
A.6.7 in the Data Requirements Dictionary Part III. Since the variables FRAMECOUNTER and 
SUBFRAMECOUNTER are part of INITIALIZATION DATA, they will be initialized at this 
time. FRAME COUNTER will be initialized to a value representing the next frame to be 
executed, while SUBFRAME COUNTER will always be initialized to the value one, which 
implies that the first subframe of the first frame to be executed will always be the sensor 
processing subframe. Although a terminal descent trajectory begins with FRAME COUNTER 
initialized to the value one, the option exists for starting execution at some point other than at the 
beginning of the trajectory, i.e., FRAMECOUNTER may be initialized to a value greater than 
one. 
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Figure A.3.1 DFD 2: RUN GCS 


EXTERNAL RUN PARAMETERS 
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Figure A.3.2 CFD 2: RUN GCS 


EXTERNAL 


RUN PARAMETERS 
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Table A.3.1 C-Spec 2: RUNGCS 



"SP" 

"GP" 

"CLP" 

"CP" 

SP DONE 

GP DONE 

CLP DONE 

CP DONE 

RENDEZVOUS 

RUNDONE 

~SP DONE & 
~GP DONE & 
-CLPDONE & 
~CP DONE 


1 


2 





"TRUE" 


SP DONE & 
CP DONE 


1 


2 

"FALSE" 



"FALSE" 

"TRUE" 


GP DONE & 

CP DONE & 

GP PHASE ~= 5 



1 

2 


"FALSE" 


"FALSE" 

"TRUE" 


CLP DONE & 
CP DONE 

1 



2 



"FALSE" 

"FALSE" 

"TRUE" 


GP DONE & 
CP DONE & 
GP PHASE = 5 

■ 



■ 






"TRUE" 
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A.4 LEVEL 3 FLOW DIAGRAMS AND C-SPECS 


Figure A.4.1 DFD2.1:SP - SENSOR PROCESSING 


RUN PARAMETERS EXTERNAL 
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Figure A.4.2 CFD 2. 1 : SP - SENSOR PROCESSING 


RUNPARAMETERS 


EXTERNAL 



GUIDANCESTATE 


SEN SOROUTPUT 
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Table A.4.1 C-Spec2.1: SP - SENSOR PROCESSING 



"ASP 

ARSP" 

"TDLRSP" 

“GSP” 

‘TSP” 

“TDSP” 

ASP_ 

DONE 

ARSP_ 

DONE 

TDRLSP_ 

DONE 

GSP_ 

DONE 

TSP_ 

DONE 

TDSP_ 

DONE 

SP_ 

DONE 

~ASP_DONE & 
~ARSP_DONE & 
~TDLRSP_DONE & 
~GSP_DONE & 
~TSP_DONE & 
-TDSPJDONE & 
~SP DONE 

2 

2 

2 

2 

1 

2 








ASP_DONE & 
ARSP DONE & 
TDLRSP DONE & 
GSP_DONE & 

TSP DONE & 
TDSPDONE & 
-SPDONE 







“FALSE” 

“FALSE” 

“FALSE” 

“FALSE” 

“FALSE” 

“FALSE” 

“TRUE” 
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Figure A.4.3 DFD 2.3: CLP - CONTROL LAW PROCESSING 


SENSOR_OUTPUT RUNPARAMETERS GUID AN CEST ATE 
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Figure AAA CFD 2.3: CLP - CONTROL LAW PROCESSING 


SENSOR OUTPUT RUN PARAMETERS GUIDANCE STATE 



EXTERNAL 
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Table A.4.2 C-Spec 2.3: CLP - CONTROL LAW PROCESSING 



"AECLP" 

"RECLP" 

"CRCP" 

AECLP DONE 

RECLP DONE 

CRCP DONE 

CLP DONE 

-AECLP DONE & 
-RECLP DONE & 
-CROP DONE & 
-CLP DONE 

1 

1 






AECLP DONE & 
-CRCP DONE & 
-CLP DONE 


1 

1 





AECLP DONE & 
RECLP DONE & 
CRCP DONE & 
-CLP DONE 




"FALSE" 

"FALSE" 

"FALSE" 

"TRUE" 
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SCHEDULING 

The execution of one frame consists of the execution of the Sensor Processing 
Subframe, the Guidance Processing Subframe, and the Control Law Processing 
Subframe, in that order. Within each subframe, the functional units which are to be 
executed are listed in Table A.4.3. Within each of the three subframes, 
GCSSIMRENDEZVOUS should be executed before executing any of the functional 
units, and the functional unit CP should be executed last. In the first and third subframes, 
there are also some sequencing constraints to be imposed upon certain functional units 
due to the fact that certain data is output from one unit and input to another unit: In the 
sensor processing subframe, TSP should be executed before ASP, and TSP should be 
executed before GSP. In the control law processing subframe, AECLP should be 
executed before CRCP. Within any given subframe, the order of execution of functional 
units not specifically mentioned here is immaterial. 

Each functional unit will be executed every frame in the particular subframe in 
which it is included in Table A.4.3. Execution of the GCS may begin at any frame 
number and should operate as if it had been running from the beginning of the trajectory 
(frame number 1). On the first, and subsequent, calls to GCS SIM RENDEZVOUS, 
FRAMECOUNTER and SUBFRAMECOUNTER will be returned to the 
implementation containing the correct values for operation. 

Table A.4.3 FUNCTIONAL UNIT SCHEDULING 


Sensor Processing Subframe (Subframe 1) 

ARSP 

ASP 

CP 

GSP 

TDLRSP 

TDSP 

TSP 

Guidance Processing Subframe (Subframe 2) 

CP 

GP 

Control Law Processing Subframe (Subframe 3) 

AECLP 

CP 

CRCP 

RECLP 


The GCS software must meet all the requirements for a particular frame for any 
specific value of the variable FRAME COUNTER. The software must be capable of 
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executing continuously one frame after another until specified tennination conditions are 
met, at which time it must tenninate itself according to specified termination procedures. 

The termination conditions and procedures are: GCS should check whether to 

terminate itself in each frame immediately after executing the Control Law Processing 
subframe. At that time if the value of the variable GP PHASE is equal to 5, then GCS 
should terminate itself gracefully (without any exception conditions). In this case, the 
implementation should terminate at the end of the present subframe, i.e., it should 
execute the functional unit Communications Processing and then terminate without 
calling GC S_S IM RENDEZ V OU S . 

5 P-SPECS FOR LEVELS 3 and 4 


AECLP -- Axial Engine Control Law Processing (P-Spec 2.3.1) 


PURPOSE The AECLP functional unit computes the valve settings for each of the three main 
(axial) engines. Measurements of the vehicle's velocity, acceleration, and roll rates are combined 
to produce error signals for the pitch, yaw, and thrust of the vehicle. These error signals are then 
mixed to produce the axial engine valve settings. 

INPUT 


AE SWITCH 

AE TEMP 

A ACCELERATION 

CHUTE RELEASED 

CL 

CONTOUR CROSSED 

DELTA T 

ENGINES ON ALTITUDE 

FRAME COUNTER 

FRAME ENGINES IGNITED 

FULL UP TIME 

GA 

GAX 

GP1 

GP2 

GPY 

GP ALTITUDE 

GP ATTITUDE 

GP ROTATION 

GP VELOCITY 

GQ 

GR 

GRAVITY 

GV 

GVE 

GVEI 

GVI 

GW 

GWI 

INTERNAL CMD 

OMEGA 

PE INTEGRAL 

PE MAX 

PE MIN 

TE DROP 

TE IN IT 

TE INTEGRAL 

TE LIMIT 

TE MAX 

TE MIN 

VELOCITY ERROR 

YE INTEGRAL 

YE MAX 

YE MIN 


OUTPUT 


AECMD 

AESTATUS 

AETEMP 

INTERN ALCMD 

PEINTEGRAL 

TEINTEGRAL 
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TEL1MIT YEINTEGRAL 

PROCESS The reader should refer to section A. 9 for notes on integration. Note that once the 
correct value of AECMD has been determined, it will automatically be transmitted to the 
engines during the next call to the GCS S1M RENDEZVOUS routine provided in the GCS S1M 
rendezvous package. (See section A.8. Implementation Notes). Computation of the axial engine 
valve settings requires the following steps: 

z processing when axial engines are off 

• IF AESWITCH is set to OFF, then perform the following steps: 

•• Set all elements of AE CMD to 0 

•• Proceed directly to the step "SET AXIAL ENGINE STATUS TO HEALTHY." 

z processing when axial engines are on 

The variable CL is used here as a subscript. Explanations for the variables CL and 
VELOCITY ERROR are provided in functional unit 2.6 GP. The variables PE INTEGRAL, 
YE INTEGRAL, and TEINTEGRAL will be initialized by INIT GCS. 

• If AE SWITCH is set to ON then perforin the following steps: 

(Note: p v , q v , and r v are the current elements of GP ROTATION; i v , y v , and i v are 
the current elements of GP VELOCITY; x v is the current x component of 
AACCELERATION.) 

DETERMINE ENGINE TEMPERATURE 

•• Set AE TEMP according to Table A. 5.1 


Table A. 5.1 DETERMINATION OF AXIAL ENGINE TEMPERATURE 


CURRENT STATE 

ACTION 

AE TEMP 

GP ALTITUDE 

(FRAME COUNTER - 
FRAME ENGINES IGNITED ) ■ 
DELTA T 

AE TEMP 

cold 

< ENGINESONALTITUDE 

< FULL UP T IME 

warming-up 

warming-up 

< ENGINES ON ALTITUDE 

> FULL UP TIME 

hot 


COMPUTE LIMITING ERRORS FOR PITCH 


•• PE INTEGRAL = PE INTEGRAL + 
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where to is the time at the beginning of this frame and t is the time at the 
end of this frame. 


•• P e L =GQ(CL)-q v +GW(CL)- 



+ GWI(CL) ■ PE _ INTEGRAL 


•• If P e L < PE JAIN (CL) then set P' e to PEMIN(CL). 
•• If Pe > PE MAX(CL) then set p/' to PE MAX(CL). 
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COMPUTE LIMITING ERROR FOR YAW 


•• YE _ INTEGRAL = YE_ INTEGRAL + f f^-dt , 

J 'o \x v \ 

where tg is the time at the beginning of this frame and t is the time at the 
end of this frame. 


Y e L = -GR(CL)r v +GV(CL) 


+ GVI(CL) ■ YE INTEGRAL 


•• If Yg <YE _MIN(CL) then set Y[', to YE_MIN(CL). 


•• If Y e l > YE MAX (CL) then set Y L e to YEMAX(CL). 


COMPUTE LIMITING ERROR FOR THRUST 

•• If CONTOURCROSSED is set to "contour not crossed", then proceed 
directly to the step "COMPUTE PITCH, YAW, AND THRUST ERRORS." 


•• If CONTOUR CROSSED is set to "contour crossed", then perform the 
following steps: 


*•* TE _ INTEGRAL = TE _ INTEGRAL + f ' (VELOCITY _ ERROR) dt 

Jt Q 

where to is the time at the beginning of this frame and t is the time at 
the end of this frame. 

••• Solve the following equation analytically in order to calculate the value 
for TELIMIT: 

— (TE _ LIMIT)+OMEGA ■ TE _ LIMIT 

dt 

GA 

- GAN ■ (x v +GRAVITY ■ GP _ ATTITUDE (1,3,0))+ 

GVE ■ VELOCITY _ ERROR+G VEI(CL ) ■ TE _ INTEGRAL 

... If TE LIMIT <TE MIN (CL) then set TE LIMIT to TE MIN(CL). 

... If TE _ LIMIT >TE _ MAX (CL) then set TELIMIT to TEMAX(CL). 
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COMPUTE PITCH, YAW, AND THRUST ERRORS 


•• Compute pitch error (P e ), Yaw Error (Y e ), and Thrust Error (T e ), according 
to Table A. 5. 2 


Table A. 5. 2 DETERMINATION OF ERROR TERMS 


CURRENT STATE 

ACTIONS 

AESWITCH 

CHUTE 

RELEASED 

CONTOUR 

CROSSED 

Pe 

Ye 

Te 

1 

1 

1 

P L 

1 e 

y l 

1 e 

TELIMIT 

1 

1 

0 

P L 

1 e 

y l 

1 e 

TEDROP 

1 

0 

0,1 

GQ(CL) • q v 

- GR(CL)- r v 

TE IN IT 


COMPUTE AXIAL ENGINE VALVE SETTINGS 

Given pitch, yaw, and thrust errors, ( P e ,Y e , T e ), the valve settings (AECMD) for each 
of the three main engines are calculated as: 



' GP\ 

0 

T 


( p \ 

± e 

INTERN ALCMD = 

GP2 

-GPY 

1 

X 

Y e 


k GP2 

GPY 

u 


\T e ; 


which will result in each element of the INTERNALCMD vector being a real value. 
This value should be converted into an integer value between 0 and 127 and placed into 
the appropriate element of the AE CMD vector. The mapping for the conversion from 
real to integer values for each of the three elements should be as follows: 


Table A.5.3 DETERMINATION OF AXIAL ENGINE COMMANDS 


CURRENT STATE 

ACTIONS 

INTERNALCMD 

AECMD 

I <0.0 

A = 0 

0.0 <I< 1.0 

0< A< 127 

1.0 < I 

A = 127 


Note: "I" represents the appropriate element of the vector INTERNAL CMD 
"A" represents the appropriate element of the vector AECMD 

with INTERN ALCMD between 0 and 1.0 being converted linearly to a value of 

AE CMD between 0 and 127. Each value for AE CMD is to be rounded to the nearest 

integer, where rounding is defined as follows: 
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Let x represent the real value that is to be rounded 
Then, AECMD = the integer part of (x+0.5) 

^ SET AXIAL ENGINE STATUS TO HEALTHY 
• Set AESTATUS to healthy. 
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ARSP — Altimeter Radar Sensor Processing (P-Spec 2.1.2) 

PURPOSE The vehicle has one altimeter radar. The ARSP functional unit reads the altimeter 
counter provided by this radar and converts the data into a measure of distance to the surface. 

INPUT 



PROCESS The processing of the altimeter counter data (ARCOUNTER) into 
the vehicle's altitude above the planet's terrain depends on whether or not an echo is 
received by the altimeter radar for the current time step. The distance covered by the 
radio pulses emitted from the altimeter radar is directly proportional to the time between 
transmission and reception of its echo. A digital counter (AR COUNTER) is started as 
the radar pulse is transmitted. The counter increments AR FREQUENCY times per 
second. If an echo is received, the lower order fifteen bits of AR COUNTER contain the 
pulse count, and the sign bit will contain the value zero. If an echo is not received, 
AR COUNTER will contain sixteen one bits. 

V ROTATE VARIABLES 

• Rotate ARALTITUDE, AR STATUS, AND K ALT. 

v determine altitude 

• If an echo is received, perform the following: 

•• Convert the AR COUNTER value to a distance to be returned in the variable 
AR ALTITUDE according to the following equation: 

AR_ COUNTER • 3 x 10 8 — 

AR ALTITUDE = see - 

AR_ FREQUENCY -2 
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• If an echo is not received, compute ARALTITUDE as follows: 

•• If all four previous values of ARSTATUS are healthy: 

••• In order to smooth the estimate of altitude, fit a third-order polynomial to 
the previous four values of AR ALTITUDE. 

••• Use this polynomial to extrapolate a value for AR ALTITUDE for the 
current time step. 

•• If any of the previous four values of AR STATUS is failed: 

••• Set the current value of AR ALTITUDE equal to the previous value of 
ARALTITUDE. 

K SET ALTIMETER RADAR STATUS 

• Set the current values for AR STATUS and KALT according to TABLE A.5.4. 


Table A.5.4 DETERMINATION OF ALTITUDE STATUS 


CURRENT STATE 

ACTIONS 

ECHO RETURNED? 

All 4 previous 
AR STATUS values 
healthy? 

ARSTATUS 

KALT 

yes 

d 

healthy 

1 

no 

yes 

failed 

1 

no 

no 

failed 

0 


Note: "d" = don't care condition 
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ASP -- Accelerometer Sensor Processing (P-Spec 2.1.1 


PURPOSE Three accelerometers, located at the vehicle's center of gravity, are slightly 
misaligned along the vehicle's 3c v , \\, , and z v axes. Each accelerometer produces a 16-bit binary 
value (ACOUNTER), represented as the magnitude portion of a sign magnitude number which 
is a linear function of the acceleration along its axis. The sign of the counter will always be 
positive, but the offset given in A B1AS will be negative or zero. The Acceleration Sensor 
Processing ( ASP) functional unit provides measures of the vehicle accelerations through the 
conversion and digital filtering of this raw accelerometer data. 


INPUT 


ALPHAMAT RIX 

ATMOSPHERICTEMP 

AACCELERATION 

AB1AS 

ACOUNTER 

AGAINO 

ASCALE 

ASTATUS 

G1 

G2 


OUTPUT 


A ACCELERATION 


A STATUS 


PROCESS The processing of the accelerometer data (ACOUNTER) into vehicle accelerations 
(AACCELERATION) requires the following steps: 

S ROTATE VARIABLES 

• Rotate A_ ACCELERATION and ASTATUS. 

v adjust gain for temperature 

The standard gain (A GAIN O) must be adjusted for the effects of temperature prior to the 
conversion of the raw accelerometer values. The adjusted gain is a quadratic function of the 
ambient temperature (ATMOSPHERICTEMP) and the standard gain. 

• Adjust the gain for temperature as follows: 


AGAINO) = AGAINO(t) + (G1 • ATMOSPHERI CTEMP) 

+ (G2 ■ ATMOSPHERI C_TEMP 2 ) 

where i ranges from 1 to 3 and represents the three directions x, y, and z, and where 
A GAIN O is the standard gain. 
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V REMOVE CHARACTERISTIC BIAS 


Each accelerometer has a characteristic DC bias (A_B1AS) which must be removed from the 
signal prior to conversion. The acceleration is a linear function of its ACOUNTER value 
where the gain specifies the slope and the offset (AB1AS) specifies the intercept. 

• Remove the bias as follows: 

A_ACCELERATION_M(i) = A BIAS(z) + A GAIN(i) * ACOUNTER(z) 
where i ranges from 1 to 3 and represents the three directions x, y, and z. 

V CORRECT FOR MISALIGNMENT 

Each accelerometer is slightly misaligned from the true vehicle axes. The multiplier matrix 
(ALPHAMATRIX) which is shown below, is based on small angle approximations and 
corrects for this misalignment. It is used for transforming the measured acceleration data into 
the true vehicle accelerations. 


ALPHA MATRIX = 


1 -« xz 
a yz 1 


V 


-a 


zy 


a 7 


<*xy 

V v 


a xy defines the angle of rotation about the vehicle's y v axis between the x v axis and 
the misaligned x v axis. The other misalignment angles are defined similarly, based 
upon a right-handed coordinate system. 

• Compute preliminary current value of AACCELERATION as follows: 

A ACCELERATION = ALPHA MATRIX x A ACCELERATION _ M 

v determine accelerations and accelerometer status 

The variable ASTATUS is a four-element array in each of the three physical dimensions, 
and contains the present and previous three values of status for each accelerometer. The 
variable A ACCELERATION is a five-element array in each of the three dimensions (x, y, 
and z). A ACCELERATION contains the present and previous four values of acceleration. 


• The following steps are described for the x axis but should be performed for each axis: 

•• If one or more of the previous three values of A STATUS is unhealthy, leave the 
current value of A ACCELERATION unchanged, set the current value of 
A STATUS to healthy, and do no further processing for this axis. 

•• If all three of the previous values of A STATUS are healthy and all three of the 
previous values of A_ ACCELERATION are equal to each other, leave the current 


A-53 



value of AACCELERATION unchanged, set the current value of ASTATUS to 
healthy, and do no further processing for this axis. 

If all three of the previous values of A STATUS are healthy, and it is not true that 
all three of the previous values of A_ ACCELERATION are equal to each other, 
check for extreme values and set A STATUS and A ACCELERATION according 

to the method described below. The accelerometer processing includes filtering of 
the calculated accelerations along each axis (i.e. filtering of (x v , y v , z v ) t ), and 

ignoring or eliminating calculated accelerations which are out of range. To effect 
this filtering, the means and standard deviations for each component of acceleration 
are to be computed using the calculated accelerations from the previous three time 
steps. That is, for the current time step t and the measurement of acceleration along 
thex axis: 

••• Calculate 



which is the current sample mean 


••• Calculate 

Z^o-a ) 2 

i=t- 3 

3 

which is the current sample standard deviation. 
••• If 1/7 - x v (f)| > ASCALE • (7 



set x v (t) to ju 

set A_STATUS to unhealthy 

where x v (t) is the acceleration along the x axis for the current time 
step. Similar equations hold for eliminating outliers in the measures of 
acceleration along the y and z axes. 


otherwise 

set A_STATUS to healthy 


In summary, if the calculated acceleration for the current time step for any 
component differs from the mean by more than ASCALE times the standard 
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deviation, then that component of acceleration should be replaced by its current 
mean and A_STATUS should be set to unhealthy. 

If the calculated acceleration for any component is within the specified range of 
the mean, then the preliminary value of AACCELERATION should remain 
unchanged and A STATUS should be set to healthy. 
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CP — Communications Processing (P-Spec 2.4) 

PURPOSE Data from the vehicle sensors and guidance processor is relayed back to the 
orbiting platform for later analysis. The CP functional unit converts the sensed data into a data 
packet appropriate for radio transmission. 

INPUT 


AE CMD 

AE STATUS 

AE TEMP 

AR ALTITUDE 

AR STATUS 

ATMOSPHERIC TEMP 

A ACCELERATION 

A STATUS 

CHUTE RELEASED 

COMM SYNC PATTERN 

CONTOUR CROSSED 

C STATUS 

FRAME COUNTER 

GP ALTITUDE 

GP ATTITUDE 

GP PHASE 

GP ROTATION 

GP VELOCITY 

G ROTATION 

G STATUS 

K ALT 

K MATRIX 

PE INTEGRAL 

RE CMD 

RE STATUS 

SUBFRAME COUNTER 

TDLR STATE 

TDLR STATUS 

TDLR VELOCITY 

TDS STATUS 

TD SENSED 

TE INTEGRAL 

TS_STATUS 

YE_INTEGRAL 

VELOCITYERROR 


OUTPUT 



PROCESS The data packet (PACKET) prepared for transmission is organized to sequentially 
contain a message and a checksum. The message consists of the synchronization pattern, 
sequence number, sample mask, and data section. The data packet created will automatically be 
transmitted during the next call to GCSSIMRENDEZVOUS. 

Z SET COMMUNICATOR STATUS TO HEALTHY 

• Set C STATUS to healthy. 

The construction of the packet requires the following steps: 

Z CONSTRUCT PACKET: 

• GET SYNCHRONIZATION PATTERN 
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The synchronization pattern is provided in the variable COMMSYNCPATTERN. It is 
a 16-bit pattern dictated by the design of the receiving communications equipment. 
DETERMINE SEQUENCE NUMBER 

The sequence number identifies the packet of data that is being sent. It is a byte value in 
the range 0..255. The sequence number will be 0 during the first subframe of frame 
number 1. Sequence numbers increase by one every subframe, except that the values 
repeat after the 256th packet. The sequence number can be calculated based on the 
values of the variables FRAMECOUNTER and SUBFRAMECOUNTER. 

PREPARE SAMPLE MASK 

The sample mask is a Boolean vector where "ones" represent variables that have been 
sampled since the previous transmission. Any variables listed in Table A.5.5 that may 
have changed during the present subframe should be marked in the mask and transmitted, 
with one exception. The variable TEINTEGRAL may be changed by GP in the second 
subframe and by AECLP in the third subframe; however, TE INTEGRAL should be 
transmitted by CP only during the third subframe, and not during the second subframe. 
In the case of any "history variable", that is, one which contains a time dimension, only 
the object (scalar, vector, or array) with a time subscript of zero should be transmitted. 
Each bit position in the mask represents a particular variable listed in Table A.5.5. The 
leftmost bit of the mask corresponds to AE CMD, and moving across the mask from left 
to right, the next mask bit corresponds to the next variable in Table A.5.5 (in row order). 

PREPARE DATA SECTION 

The data section of the packet contains the sixteen bit values for the elements of the 
variables in Table A.5.5 that may have new samples available. Once it has been 
determined which variables should be transmitted for this particular subframe, those 
variables should be packed into the data section. Although the length of the variable 
PACKET is fixed, the number of bytes of PACKET which contain actual variables to be 
transmitted will vary depending on the values of FRAME COUNTER and 
SUBFRAME COUNTER. The variables to be transmitted should be concatenated so 
that there are no unused bytes between the data to be transmitted. There may however be 
unused bytes following the checksum. The data are concatenated in the order given by 
the sample mask, starting with the most significant bit (i.e. left most bit). Variables 
should be packed to the nearest byte boundary; thus, a single element of PACKET could 
contain a logical* 1 and the first byte of the variable that follows it. Arrays should be sent 
with the first index changing most rapidly. It should be noted that some arrays have 
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terms that are constant (e.g. the off-diagonal terms of KMATRIX and the diagonal 
terms of GPROTATION) and since these terms can never have "new" values, they 
should not be transmitted. The values in Table A. 5. 5 should be sent in row order, starting 
at the top of the table. The first value in alphabetical order goes next to the mask in the 
packet. 

• CALCULATE CHECKSUM 

The checksum is calculated for the message using the standard CRC-16 polynomial as 
defined in (ref. A. 11). Table A. 5. 7 illustrates the byte structure of the packet. The 
unused part of PACKET should be ignored in the calculation of the checksum. The 
checksum should be placed in the two bytes immediately following the message for this 
subframe. Refer to Appendix D for a detailed description of the packet and for specific 
instructions on the checksum calculation. 


Table A.5.5 PACKET VARIABLES 


AECMD 

AESTATUS 

AETEMP 

AR_ ALTITUDE 

ARSTATUS 

ATMO SPHERICT EMP 

A_ ACCELERATION 

ASTATUS 

CHUTERELEASED 

CONT 0 URCRO S SED 

CSTATUS 

GPALTITUDE 

GPATTITUDE 

GPPHASE 

GPROTATION 

GPVELOCITY 

GROTATION 

GSTATUS 

KALT 

KMATRIX 

PEINTEGRAL 

RECMD 

RESTATUS 

TDLRSTATE 

TDLRSTATUS 

TDLRVELOCITY 

TDSSTATUS 

TDSENSED 

TEINTEGRAL 

TSSTATUS 

VELOCITYERROR 

YEINTEGRAL 



Note: when read by rows, this table represents the alphabetical listing of variables 
that are to appear in the data section of the packet. 


Table A.5.6 SAMPLE MASK 


INFORMATION SENT 

A 

B 

C 


z 

EXAMPLE MASK 

1 

1 

0 


1 
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Note: this table gives information only on the order of the packet. The packet 
should be packed to a byte-boundary limit into integer*2 elements. 
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Table A.5.7 PACKET BYTE STRUCTURE 


Subframe 1 

Subframe 2 

Subframe 3 

CONTENTS 

Byte 

Byte 

Byte 

(Cells in bold italics with 

Positions 

Positions 

Positions 

double-line border constitute the 

1 

1 

1 

SYNCHRONIZATION 

2 

2 

2 

PATTERN 

3 

3 

3 

SEQUENCE NUMBER 

4 

4 

4 


5 

5 

5 

SAMPLE MASK 

6 

6 

6 


7 

7 

7 


8 

8 

8 





DATA SECTION 

L23 

EZ3 

45 


130 

174 

46 


131 

175 

47 

CHECKSUM 

132 

176 

48 





NOT USED 

512 

512 

512 



Note: The variables inserted into PACKET are inserted in the VAX standard byte 
order. 
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CRCP -- Chute Release Control Processing (P-Spec 2.3.3) 


PURPOSE The CRCP functional unit implements the release of the parachute which is attached 
prior to the beginning of the terminal descent phase. 


INPUT 


AE TEMP 


CHUTE RELEASED 


OUTPUT 

I CHUTE RELEASED 


PROCESS If the chute has been released, leave CHUTERELEASED unchanged and this 
signal will be automatically transmitted to the chute release mechanism during the next call to 
GCSSIMRENDEZVOUS. If the chute has not been released, the engine temperature will 
determine whether or not to release the chute. If the chute has not been released and the engines 
are hot (i.e. AE TEMP is HOT), then release the chute by setting CHUTE RELEASED to "chute 
released." 
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GP — Guidance Processing (P-Spec 2.2) 


PURPOSE GP uses the information available from ASP, ARSP, C-RCP, GSP, TDLRSP, and 
TDSP and the results of its previous computations to control the vehicle's state during terminal 
descent. 

INPUT 


AES WITCH 

AETEMP 

AR_ ALTITUDE 

A_ ACCELERATION 

CHUTERELEASED 

CL 

CONTOURALTITUDE 

CONTOURCROSSED 

CONTOURVELOCITY 

DELTAT 

DROPHEIGHT 

DROPSPEED 

ENGINESONALTITUDE 

FRAMECOUNTER 

GPALTITUDE 

GPATTITUDE 

GPPHASE 

GP_ VELOCITY 

GRAVITY 

GROTATION 

KALT 

KMATRIX 

MAXNORMALVELOCITY 

RESWITCH 

TDLR VELOCITY 
TD SENSED 

TDSSTATUS 


OUTPUT 


AESWITCH 

CL 

CONTOUR CROSSED 

FRAMEENGINESIGNITED 

GPALTITUDE 

GPATTITUDE 

GPPHASE 

GPROTATION 

GPVELOCITY 

RESWITCH 

TEINTEGRAL 

VELOCITYERROR 


ARRAYS The variables GPATTITUDE, GPALTITUDE, and GPVELOCITY are five 
element arrays in each of their history dimensions and contain enough previous values to provide 
the required history for integration in updating the vehicle and guidance states. 

PROCESS The Guidance Processor computes the velocity, altitude, and attitude to be used in 
controlling the engines. 


V ROTATE VARIABLES 

• Rotate GP ATTITUDE, GP ALTITUDE, and GP_VELOCITY. 

V SET UP THE GPROTATION MATRIX 

GROTATION contains three values: p, q, and r, in that order. These values must be placed 
into a 3x3 matrix (GP ROTATION) in the correct positions for later calculations. Note 
that GP ROTATION does not include any time histories; thus it may be convenient to use a 
temporary variable during calculation to hold the time histories of GP ROTATION or to use 
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elements directly from GROTATION; however, GPROTATION does describe the correct 
matrix orientation for operations and upon exiting from GP should contain the correct values 
for the present time step. 

• Place the values from G ROTATION into GP ROTATION as shown: 

0 r v -q v ' 

GP_ ROTATION = -r v 0 p v 

v q v ~Pv 0 ) 

•/ CALCULATE NEW VALUES OF ATTITUDE, VELOCITY, AND ALTITUDE 
The attitude, velocity, and altitude are each calculated by: 

1 . finding a rate of change from known values, and then 

2. integrating this rate of change through one time step by some method of integration 
providing the accuracy specified. That is: 

A, = A M + f' Xdt 

Jt~ 1 

where A represents the rate of change of attitude, velocity, or altitude. 

Table A. 5. 8 gives the equations for the rates of change for each of the variables 
GPATTITUDE, GP_VELOCITY, and GPALTITUDE. 

• Solve for the current values of GP ATTITUDE, GP_VELOCITY, and GP ALTITUDE 
using the equation for X t given above, Table A. 5. 8, and an appropriate integration 

method (see section A. 9 Numerical Integration Instructions). 

Table A.5.8 DIFFERENTIAL EQUATIONS 


d(GP ATTITUDE ) 

= GP_ ROTATION x GP ATTITUDE 

dt 


d(GP VELOCITY) 

= GP ROTATION x GP_ VELOCITY 

dt 

( 0 ^ 

+ GP ATTITUDE x 0 I + A _ ACCELERATION + K ^MATRIX x (TDLR_ VELOCITY - GP VELOCITY) 

kgravity) 


d(GP_ ALTITUDE) 
dt 


( (o\\ T 

GP_ A TTITUDE x 0 I x GP_ VELOCITY + K_ ALT ■ (AR_ AL TITUDE - GP_ AL TITUDE ) 

V VlJJ 


v determine if engines should be on or off 
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Note that RE SWITCH is initialized to on, while AESWITCH is initialized to off, and 
FRAMEENGINESIGNITED is initialized by INIT GCS. Use Table A.5.9 to determine 
whether to turn axial engines on (set AESWITCH to on and set 
FRAME ENGINES IGNITED) or whether to turn axial and roll engines off (set 
AE SWITCH and RE SWITCH to off). 

TABLE A.5.9 DETERMINATION OF AXIAL AND ROLL ENGINE ON/OFF SWITCHES 


CURRENT STATE 

ACTIONS 

AE_ 

SWITCH 

GP_ 

ALTITUDE 


Have engines 
been turned 
off in any 
prior frame? 

TD_ 

SENSED 

FRAME_ 

ENGINES_ 

IGNITED 

AE_ 

SWITCH 

RE_ 

SWITCH 

( J velocity _ expression ^ + 

xcomponentof GP _ VELOCITY ) 

< MAX _ NORMAL _ VELOCITY 

9 

off 

< 

ENGINES_ON_ 

ALTITUDE 

d 

no 

not sensed 

current 

FRAME_ 

COUNTER 

on 


on 

< DROP_ 
HEIGHT 

yes 

d 

not sensed 


off 

off 

on 

d 

d 

d 

sensed 


off 

off 


1 velocity _ expression = 2 • GRAVITY ■ maximum(GP_ ALTITUDE, 0) 

Note: A blank box under "ACTIONS" indicates no action is to be taken 
"d" = don't care condition 


•S DETERMINE VELOCITY ERROR 

The velocity-altitude contour consists of a set of points of which one coordinate is the altitude 
of the craft and the other coordinate is the optimal x component of velocity at the altitude 
given by the first coordinate. The altitude and optimal velocity coordinates are held in the 
CONTOUR_ ALTITUDE and CONTOUR_VELOCITY arrays respectively. The altitude 
coordinates are in the CONTOURALTITUDE array contiguous to each other, in ascending 
numerical order, beginning with the first element of the array. Any unused elements of the 
array have been filled with zeroes (the value of zero will not be used as an actual value for 
altitude). There are at least two valid non-zero altitude values in the table. The two arrays are 
related such that for a given value of altitude in CONTOUR ALTITUDE, the corresponding 
value in CONTOUR VELOCITY is the optimal velocity x component at that altitude. For 
any altitude that is not explicitly listed in CONTOUR ALTITUDE, the value for optimal 
velocity can be found by linear interpolation (or extrapolation if the value is outside the range 
of the altitude array). The velocity error (VELOCITY ERROR) is the difference between 
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the actual x component of the velocity of the craft (GPVELOCITY) and the optimal velocity 
x component at the vehicle altitude. Figure A.5.1 illustrates the velocity-altitude contour. 

• The optimal velocity should be calculated by finding the present altitude in 
CONTOURALTITUDE and then locating the corresponding velocity in 
CONTOURVELOCITY, using interpolation or extrapolation if necessary. Let 
optimal ^velocity represent the value obtained from the contour arrays, whether extracted, 
interpolated, or extrapolated. 

• Calculate VELOCITYERROR as follows: 

VELOCITYERROR = x component of GPVELOCITY - optimal velocity 

V DETERMINE IF CONTOUR HAS BEEN CROSSED 

• If GP ALTITUDE < ENGINES ON ALTITUDE, then check whether the contour has 
been crossed as follows: 

•• If CONTOUR_CROSSED = "contour not crossed" and VELOCITY ERROR > 0, then 
set CONTOUR CROSSED to "contour crossed". Otherwise CONTOUR_CROSSED 
should remain unchanged. 

Figure A.5.1 shows two possible trajectories, with the point along each where the 
contour is first sensed and also an example of VELOCITY ERROR. Note: the altitude 
where the engines are turned on should be the earliest point to check crossing the contour, 
even though the trajectory may have crossed the contour at some greater altitude. 
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Figure A.5.1 VELOCITY-ALTITUDE CONTOUR 



v determine guidance phase 

• The guidance phase (GPPHASE) is determined according to the events in Table A.5.10. 
These phases are based upon information that may be provided by processes other than 
the guidance processor. 

The current phase (GP PHASE) and the event are to be used where appropriate to reset 
GP PHASE to the next phase. If there is no combination of current phase and event 
from the table that is true, then GP PHASE should not be changed. Note that the two 
columns labeled "CURRENT STATE DESCRIPTION" and "NEXT STATE 
DESCRIPTION" are for informational purposes only, and are not used in the setting of 
GP PHASE. 
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Table A.5.10 DETERMINATION OF GUIDANCE PHASE 


CURRENT STATE 


NEXT STATE 

ACTION 


GP 

PHASE 

CURRENT STATE 
DESCRIPTION 

EVENT 

GP 

PHASE 

NEXT STATE 
DESCRIPTION 

1 

Chute attached 
Engines off 

Touch Down not sensed 

Altitude for turning engines on is 
sensed 

2 

Chute attached 
Engines on 

Touch down not sensed 

2 

Chute attached 
Engines on 

Touch down not sensed 

Axial Engines become hot and 
the chute is released 

3 

Chute released 
Axial Engines Hot 
Touch down not sensed 

2 

Chute attached 
Engines on 

Touch down not sensed 

Touched down is sensed 

5 

Chute attached 
Engines off 
Touch down sensed 

3 

Chute released 
Axial Engines Hot 
Touch down not sensed 

Altitude < DROP HEIGHT and 
TDSSTATUS = healthy and 
Touch down not sensed and 

4 

Chute released 

Engines off 

Touch down not sensed 

velocity_expression^ 

+ xcomponentofGP VELOCITY) 
< MAX NORMAL VELOCITY 

3 

Chute released 
Axial Engines Hot 
Touch down not sensed 

Altitude < 

DROP HEIGHT and 
TDSSTATUS = failed 

5 

Chute released 

Engines off 

Touch down not sensed 

3 

Chute released 
Axial Engines Hot 
Touch down not sensed 

Touch down is sensed 

5 

Chute released 
Engines off 
Touch down sensed 

4 

Chute released 

Engines off 

Touch down not sensed 

Touch down is sensed 

5 

Chute released 
Engines off 
Touch down sensed 

4 

Chute released 

Engines off 

Touch down not sensed 

TDSSTATUS = failed 

5 

Chute released 

Engines off 

Touch down not sensed 


1 velocity _ expression = 2 • GRAVITY ■ maximum(GP_ ALTITUDE, 0) 


• PHASE 1 : If the altitude provided by the guidance processor is less than or equal to the 
ENGINES ON ALTITUDE, set GP_PHASE = 2. 

• PHASE 2: If the axial engines have become hot and the parachute has been released, set 
GPPHASE = 3. If touch down is sensed, set GPPHASE = 5. 

• PHASE 3: If touch down has not been sensed and DROPHEIGHT has not been 

reached, then control the axial and roll engines to cause the lander to follow a gravity- 
turn steering descent. If DROP HEIGHT is reached and touch down is not sensed and 
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V 2 • GRAVITY ■ maximum(67 J _ ALTITUDES) ) + x component of GP_ VELOCITY 
< MAX_ NORMAL _ VELOCITY 

and TDSSTATUS = healthy, then set GP_PHASE = 4. If DROPHEIGHT is reached, 
and TDS STATUS = failed, then set GPPHASE = 5. If touch down is sensed, then set 
GPPHASE = 5. 

• PHASE 4: If touch down has not been sensed and TDS STATUS is healthy, then take no 
action. If TDS STATUS is failed, then set GP PHASE to 5. If touch down has been 
sensed, set GP PHASE to 5. 

V DETERMINE WHICH SET OF CONTROL LAW PARAMETERS TO USE 

The "Control Law Parameters" are a subset of the variables in the global data store named 
"RUNPARAMETERS." This subset consists of the following variables: GVEI, GV, GVI, 
GR, GW, GWI, GQ, PEMIN, PEMAX, TE MIN, TE MAX, YEMIN, and YE MAX. 
Note that each one of these variables is an array of two elements. The elements with a 
subscript of one will be referred to as the "first" set of Control Law Parameters, while the 
elements with a subscript of two will be referred to as the "second" set of Control Law 
Parameters. 

The variable CL is used to control which set of Control Law Parameters is used in the control 
laws at any given time by the functional unit AECLP. The functional unit GP must determine 
the value of CL for use by AECLP. The variable CL has two valid values, namely "first" 
which means that the first set of Control Law Parameters should be used by AECLP, and 
"second" which means that the second set of Control Law Parameters should be used by 
AECLP in the equations for P e , Y e , P T e , , and TE LIMIT. See the Data Requirements 

Dictionary for the actual numeric values for CL which correspond to "first" and "second." 
The variable CL is initialized to the value "first" by INIT GCS, and thus the first set of 
parameters will be used by AECLP until CL is changed. The second set of Control Law 
Parameters should be used by AECLP at the first point where the lander crosses the constant- 
velocity part of the Velocity-Altitude contour. The constant-velocity part of the contour 
consists of the four sets of coordinates with the smallest altitudes and for which the 
CONTOUR VELOCITY elements are exactly equal to the value DROP_SPEED. The 
GUIDANCE PROCESSOR (GP) must determine when to begin using the second set of 
Control Law Parameters, as follows: 
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If the following conditions are true: 

CL = first, and 

optimalvelocity = DROPSPEED, and 
x component of GP_VELOCITY < DROP_SPEED 
Then 

Set CL = second 
SetTE INTEGRAL = 0.0 
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GSP -- Gyroscope Sensor Processing (P-Spec 2.1.4) 


PURPOSE Three fiber-optic ring gyroscopes are located on the lander, one for each of the x, 
y, and z axes. The Gyroscope Sensor Processing (GSP) functional unit provides a measure of the 
vehicle's rotation rates through the conversion and filtering of the raw gyroscope data. 

INPUT 


ATMO SPHERICTEMP 
G4 

GGAINO 

GROTATION 

G3 

GCOUNTER 

GOFFSET 


GROTATION 

GSTATUS 


PROCESS The output from each of the gyroscopes is a 16-bit quantity (GCOUNTER) divided 
into 2 parts: the lower 14 bits represent the vehicle's rate of rotation about that axis and the high- 
order bit represents the direction of this rotation. This is a sign-magnitude representation of the 
counter value that only uses the lower 14 bits of the magnitude portion of the number. Following 
is a map of G COUNTER: 


15 

14 

13 

12 

11 


0 

D 

X 

MAGNITUDE 


where D = direction, and X = unused. The high bit set to 1 indicates a negative rotation 
consistent with a right-handed coordinate system. 

S ROTATE VARIABLES 

• Rotate G_ROTATION. 

V ADJUST GAIN 

The standard gain (GGAINO) must be adjusted for the effects of temperature prior to the 
conversion of the raw gyroscope values. The adjusted gain is a quadratic function of the 
ambient temperature (ATMOSPHERICTEMP) and the standard gain. 

That is, 

G_GAIN(/) = G_GAIN_0(O + (G3 • ATMO SPHERIC _ TEMP) 

+ (G4- ATMO SPHERIC_ TEMP 2 ) 
where i ranges from 1 to 3 and represents the three directions x, y, and z. 
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V CONVERT G COUNTER 


The rotation rate is linear with respect to the unprocessed gyroscope values, i.e. the lower 14 
bits must be converted. G GAIN is the multiplier for this conversion and GOFFSET is the 
constant offset. The equation for converting counter to rotation then becomes: 

G ROTATION(i') = G_OFFSET(7) + G_GAIN(/) * (G_COUNTER(/)) 
where i ranges from 1 to 3 and represents the three directions x, y, and z. 

V SET GYROSCOPE STATUS TO HEALTHY. 

• Set G STATUS to healthy. 
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RECLP — Roll Engine Control Law Processing (P-Spec 2.3.2) 


PURPOSE RECLP generates the roll engine command which controls the firing pulse and 
direction of the roll engines. 

INPUT 


DELTAT 

GROTATION 

PI 

P2 

P3 

P4 

RESWITCH 

THETA 

THETA1 

THETA2 


OUTPUT 


RECMD 

RESTATUS 

THETA 



PROCESS Roll control of the lander is achieved by generating the roll commands as functions 
of the differences between the actual and desirable values for the roll angle and rate. These 
differences are limited, and the control commands are proportional to them. Note that once the 
roll command (RECMD) has been set with the correct value, it will automatically be sent to the 
engines during the next call to GCS S1M RENDEZVOUS. The steps to be performed are as 
follows: 


z DETERMINE IF ENGINES ARE ON 

• If RES WITCH is off, then set RECMD to 1, and proceed directly to the step "SET 
ROLL ENGINE STATUS TO HEALTHY." 

Z DETERMINE PULSE INTENSITY AND DIRECTION 

• The pulse intensity and direction are derived from the graph shown in Figure A.5.2 using 
(p v ) f . For each region of the graph, the intensity is given, followed by the direction 

inside parentheses. Note that the x axis represents the integral of the roll rate. This is 
really the present angle of roll. This integral should be calculated by Euler's method (see 
section A. 9). As an example, THETA = THETA + (integral of roll rate for this frame). 
The variable THETA will be initialized by INIT GCS. Note that when the vehicle status 
is located on a boundary between two or more roll command regions, the lowest intensity 
signal should be used to avoid over-commanding the engines. One should refer to the 
Data Requirements Dictionary under RE CMD for the actual values for intensity and 
direction. 
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V DETERMINE ROLL ENGINE COMMAND 


• The pulse intensity and direction are packed into the lowest three lower-order bits of the 
actual roll engine command (RECMD) as shown: 


15 

14 

13 

■ 

3 

2 

1 

0 

X 

X 

X 


X 

I 

I 

D 


where X = unused, I = intensity, and D = direction. The bits marked "X = unused" in 
RE CMD must be left at 0. 


V SET ROLL ENGINE STATUS TO HEALTHY 

• Set RE STATUS to healthy. 


Figure A. 5. 2 GRAPH FOR DERIVING ROLL ENGINE 
COMMANDS 

A P 

Maximum (CW) 


Maximum (CCW) 


Off (CW) 


Maximum (CW) 


Intermediate (CW) 


-a, 


- 0 , 


Minimum 

(CCW) 


Off (CW) 


|Off (CW 

_ _ 


Minimum 

(CW) 


Intermediate (CCW) 


Maximum (CCW) 


Off (CW) 


THETA 

Maximum (CW) 


Maximum (CCW) 



CW CCW 


Note: " Off", "Minimum", "Intermediate", and "Maximum" are 
Intensities. 

"CW" and "CCW" are Directions, as viewed from 
below the craft.. 

"CW" = Clockwise; "CCW" = Counterclockwise 
Note: PI < P2 < P3 < P4 and 01 < 02 
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TDLRSP -- Touch Down Landing Radar Sensor Processing (P-Spec 2.1.3) 


PURPOSE A single touch down landing radar (TDLR) gauges the velocity of the vehicle during 
terminal descent. This radar is a doppler radar with four radar beams, each of which emanates 
from the vehicle's center of gravity with a slight offset from the vehicle's x v axis. The radar 
beams form the edges of the pyramid as shown in Figure A.5.3. 

The Touch Down Landing Radar Sensor Processing (TDLRSP) functional unit 
converts measurements of the frequency shift of each beams reflection into vehicle 
velocities; however, the receivers associated with each beam may not find a usable 
reflection. If no usable reflection is found, the receiver returns a status of beam in search 
mode (unlocked). 

INPUT 


DELTAT 

FRAMEBEAMUNLOCKED 

FRAMECOUNTER 

KMATRIX 

TDLRANGLES 

TDLRCOUNTER 

TDLRGAIN 

TDLRLOCKTIME 

TDLROFFSET 

TDLRSTATE 

T DLRVELOCIT Y 



OUTPUT 


FRAMEBEAMUNLOCKED 

KMATRIX 

TDLRSTATE 

TDLRVELOCITY 

TDLRSTATUS 


PROCESS The value returned by each beam (TDLRCOUNTER) is proportional 
to the beam frequency shift down that beam, which is, in turn, proportional to the velocity 
down that beam. The processing of the TDLR COUNTER data into the component 
velocities along the vehicle's x, y, and z axes requires the following steps: 


K ROTATE VARIABLES 

• Rotate TDLR VELOCITY and K MATRIX. 


A-74 





Figure A.5.3 DOPPLER RADAR BEAM LOCATIONS 


I 

/ 


/I “1 



x 


-> 

y 


K DETERMINE RADAR BEAM STATES 

The processing of the four radar beams depends on the current state of the radar, i.e. whether 
or not each of the four beams is searching or in lock, and also upon the previous states of the 
beams. Note that at the beginning of each trajectory, FRAMEBEAMUNLOCKED will be 
set to zero, thus meaning that the beam has never been unlocked. If the receiver for a beam 
does not sense an echo (i.e. the beam is in search mode), the corresponding 
TDLR COUNTER value will be zero. Note that a beam which becomes unlocked will be 
ignored for TDLRLOCKTIME seconds. 

• Use Table A. 5. 11 to determine the state (TDLRSTATE and 
FRAME BEAM UNLOCKED) for each of the four beams. 
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Table A.5. 1 1 DETERMINATION OF RADAR BEAM STATES 


CURRENT STATE 

ACTIONS 

TDLR 

STATE 

TDLR 

COUNTER 

DELTA _ T 

■ (FRAME _ COUNTER - FRAME _ BEAM _ UNLOCKED ) 
> TDLR _ LOCK _ TIME ? 

TDLR 

STATE 

FRAME BEAM 
UNLOCKED 

locked 

0 

d 

unlocked 

current 

FRAMECOUNTER 

unlocked 

* o 

yes 

locked 


unlocked 

0 

yes 


current 

FRAMECOUNTER 


Note: A blank box under "ACTIONS" indicates no action is to be taken 
"d" = don't care condition 


v 7 DETERMINE BEAM VELOCITIES 

A beam velocity is a linear function of its TDLR COUNTER value where the gain 
(TDLRGAIN) specifies the slope and the offset (TDLROFFSET) specifies the intercept. 

• Calculate the beam velocities as follows: 

B(z) = TDLR OFFSET + TDLR GAIN * (TDLR COUNTER(O) 
where i ranges from 1 to 4 and represents the four radar beams. 

V PROCESS THE BEAM VELOCITIES 

• Use Table A.5.12 to calculate values for B x , B v , and B. , which are the processed beam 
velocities. Note that in Table A.5.12, B / is shorthand for B(z), where i ranges from 1 to 

4. Note also that the knowledge of which beams are in lock is used to determine which 
line of the table to use in order to calculate B x , B y , and B . . 

V CONVERT TO BODY VELOCITIES 

• In order to convert the processed beam velocities to body velocities 
(TDLR VELOCITY), use the following equations, which make use of the angles a, (1 
and y (TDLR ANGLES) which are the offsets of the beams from the body axes: 

TDLR VELOCITY (1) = 

— cosa 

TDLR _ VELOCITY (2) = 

TDLR VELOCITY (3) = 
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K SET VALUES IN KMATRIX 

When calculating the vehicle velocity, the Guidance Processor must know which components 
of the body velocities are usable. A value of one in the diagonal element of the K MATRIX 
indicates that the corresponding velocity should be used, while a value of zero indicates that it 
should not. 

• Use Table A.5.12 to set the values for K , K , and K in K MATRIX, (again on the 

x y z ~ 

basis of which beams are in lock), as follows: 


K MATRIX = 


K x 

0 

0 


0 

Ky 

0 


K 


zJ 


The off-diagonal elements of K MATRIX should not be updated. 
K SET TDLRSTATUS 

• Set all elements of TDLR STATUS to healthy. 


Table A.5.12 PROCESSING OF DOPPLER RADAR BEAMS IN LOCK 


CURRENT STATE 

ACTIONS 

BEAMS 
IN LOCK 

kx 

K x 

B y 

K v 

k 

K z 

none 

0 

0 

0 

0 

0 

0 


0 

0 

0 

0 

0 

0 

b 2 

0 

0 

0 

0 

0 

0 

b 3 

0 

0 

0 

0 

0 

0 

B 4 

0 

0 

0 

0 

0 

0 

B l, b 2 

0 

0 

(Bi-Bi)/ 2 

1 

0 

0 

B b B 3 

0i+^y2 

1 

0 

0 

0 

0 

Bj, B 4 

0 

0 

0 

0 

(z?, - Z?4 )/2 

1 

b 2 , b 3 

0 

0 

0 

0 

(Bl - lh )/ 2 

1 

b 2, b 4 

(B 2 +B 4 )/2 

1 

0 

0 

0 

0 

b 3 , b 4 

0 

0 

0*4 - lh )/ 2 

1 

0 

0 

B l> b 2, b 3 

+ 2 

1 

(Bi-Bi)/ 2 

1 

( B i-B 3 y 2 

1 

B l, b 2, b 4 

(jh + B 4 )/2 

1 

(Bi-Bi)/ 2 

1 

(z?| - Z? 4 )/2 

1 

B l> b 3, b 4 

( B i + B i)/ 2 

1 

(«4 - lh )/ 2 

1 

(Bi-Ba)/ 2 

1 

b 2> b 3, b 4 

(B 2 + B 4 )/ 2 

1 

(«4 - B >: )/ 2 

1 

(z? 2 - z? 3 y2 

1 

B b b 2, b 3 ■ b 4 

(ft! + ft 2 +ft 3 +B 4 )/ 4 

1 

(fi, - By -B 3 + By )/ 4 

1 

(5, + ft - S 3 - B 4 )/4 

1 
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TDSP -- Touch Down Sensor Processing (P-Spec 2.1.6) 


PURPOSE The touch down sensor is attached to the end of a rod which is attached to the 
bottom of the vehicle. Its purpose is to trigger engine shutdown when the vehicle is at the correct 
distance from the surface. This shutdown is necessary to: 

• avoid the stirring up of dust and debris and 

• avoid scorching immediate area of the experiment site. 


INPUT 

OUTPUT 


TDSSTATUS 

TDCOUNTER 


TDSSTATUS 

TDSENSED 


PROCESS The touch down sensor is a simple switch at the end of a pole on the underside of the lander. 
If the sensor is functioning properly, then TDCOUNTER will contain one of only two 16-bit values, 
namely sixteen "ones", which means that touch down has been sensed, or sixteen "zeroes", which means 
that touch down has not been sensed. If the sensor has failed due to electrical noise, TD COUNTER will 
contain some combination of "ones" and "zeroes" other than all "ones" or all "zeroes". 


S DETERMINE STATUS OF TOUCH DOWN SENSOR AND WHETHER TOUCH 
DOWN HAS BEEN SENSED: 

• Use Table A.5.13 to determine whether the touch down sensor is functioning properly 
(set TDSSTATUS), and whether touch down has been sensed (set TDSENSED). Note 
that if the sensor fails, the guidance processor will decide when the vehicle has touched 
down. 


Table A.5.13 DETERMINATION OF TOUCH DOWN SENSOR AND STATUS 


CURRENT STATE 

ACTIONS 

TDSSTATUS 

TDCOUNTER 

TDSENSED 

TDSSTATUS 

healthy 

all zeroes 

not sensed 


healthy 

all ones 

sensed 


healthy 

mixture of ones & 
zeroes 

not sensed 

failed 


Note: A blank block under "ACTIONS" indicates no action is to be taken 
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TSP -- Temperature Sensor Processing (P-Spec 2.1.5) 


PURPOSE A temperature gauge on the vehicle is used to adjust the response of the 
accelerometers and gyroscopes. The gauge contains two temperature sensing devices, namely a 
solid-state sensor and a matched pair of thermocouples. The Temperature Sensor Processing 
(TSP) functional unit determines the ambient temperature, using either the solid-state sensor or 
the thermocouple pair in a manner maximizing the accuracy of the measurement. 

INPUT 


Ml 

M2 

M3 

M4 

SSTEMP 

Tl 

T2 

T3 

T4 

T HERMOTEMP 


OUTPUT 


ATMOSPHERIC TEMP 


TS STATUS 


PROCESS The temperature values from the solid-state sensor are highly quantized. The 
processing of raw temperature data from the solid-state sensor and thermocouple pair, SSTEMP 
and THERMO TEMP, is based on the solid-state sensor being less accurate than the 
thermocouple pair, but having a greater usable operating range. 

The ambient temperature (ATMOSPHERICTEMP) is to be calculated using either the solid state 
sensor value (SS TEMP) or the thermocouple sensor value (THERMO TEMP). Since the thermocouple 
sensor is more accurate, it should be used whenever possible; the solid state sensor should be used only if 
the temperature does not lie within the usable range of the thermocouple pair. 

The response of the solid-state temperature sensor is linear with respect to the 
ambient temperature and is computed using the two calibration points (Ml, Tl) and (M2, 
T2) which characterize the line. 

The response of the thermocouple pair is calibrated differently depending on the 
region (linear or parabolic) where the measurement lies (see Figure A. 5.4): 


Thermocouple linear region - The linear region is bounded by the calibration points used by the 
thermocouple sensor (i.e., [M3, T3] and [M4, T4] inclusive). Temperatures measured within 
this region are calibrated accordingly. 
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Figure A. 5. 4 CALIBRATION OF THERMOCOUPLE PAIR 
T emperature 



Note: M3 < M4 and T3 < T4 
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Thermocouple parabolic regions - The upper and lower parabolic regions extend plus or 
minus 15 percent of the difference between the measured calibration points, M4 and M3, 
respectively. These parabolic regions each intersect the line at the calibration points. 
The rate of change in temperature, with respect to the thermocouple measurements, is 
continuous at these intersections. The upper (and lower) parabolas are defined so that the 
temperature goes up (or down) as the square of the measurement value 
(THERMO TEMP). The parabolas are offset along both the temperature and 
measurement axes. By using the values of T3, T4, M3, and M4, and the fact that the 
function is continuous at the endpoints, the offsets for the parabolas may be determined, 
and the equations for the parabolas may be generated. Note that the line in the linear 
region in Figure A. 5.4 is tangent to both parabolas. 

The processing of the values SS TEMP and THERMO TEMP into an accurate 
measure of ambient temperature (ATMOSPHERICTEMP) requires several steps, as 
follows: 

S CALCULATE THE SOLID STATE TEMPERATURE 

• Use the value of SS TEMP and the equation appropriate to the solid-state linear region to 
compute the temperature. 

S DETERMINE WHETHER TO USE SOLID STATE OR THERMOCOUPLE 

TEMPERATURE 

• If the temperature derived from SS TEMP in the previous step does not fall within the 
accurate temperature response zone of the thermocouple pair (the linear as well as 
parabolic regions), then set ATMOSPHERIC TEMP to the temperature derived from 
SS TEMP and proceed directly to the step labeled "SET STATUS TO HEALTHY"; 
otherwise, proceed to the step "CALCULATE THE THERMOCOUPLE 
TEMPERATURE". 

v' CALCULATE THE THERMOCOUPLE TEMPERATURE 

• Use the value of THERMO TEMP to determine whether the temperature lies in the 
thermocouple linear or the upper parabolic or the lower parabolic region. 

• Use the value of THERMO TEMP and the equation appropriate to the particular 
thermocouple region (as determined above) to calculate ATMOSPHERIC TEMP. 

Y SET STATUS TO HEALTHY 

• Set the values of both elements of TSSTATUS to healthy. 
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A.6 DATA REQUIREMENTS DICTIONARY 


PART I. DATA ELEMENT DESCRIPTIONS 


The following template has been constructed for defining the data elements in the 
four required global data stores and the optional variables shown in Table A. 6. 5: 


NAME: 

DESCRIPTION: 

USED IN: 

UNITS: 

RANGE: 

DATA TYPE: 

ATTRIBUTE: 

DATA STORE LOCATION: 
ACCURACY: 


NAME This field gives the name of the variable used in the specification. The variable name used during 
coding must be the same as specified. 

DESCRIPTION This field gives a brief description of the variable. 

USED IN This field provides a reference to the functional units using this variable. 

UNITS This field indicates the unit of measure for the data contained in the variable being defined. 
RANGE This field specifies the acceptable range of data values for the variable. 

DATA TYPE The data type field specifies the data type to be used when declaring the variable during 
coding. 

ATTRIBUTE This field indicates whether or not the variable contains data, control information, or a data 
condition. 

DATA STORE LOCATION This field references the common region where the variable must be stored. 
ACCURACY This field dictates the degree of accuracy required for output comparisons to be made 
between implementations. In the data dictionary, accuracy is listed as N/A where accuracy is not 
applicable, or TBD where accuracy is (T)o (B)e (D)etermined later. A formal modification will be released 
when the values of the accuracy requirements have been approved. 
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NAME: A_ ACCELERATION 
DESCRIPTION: vehicle accelerations 
USED IN: AECLP, ASP, CP, GP 
meters 

UNITS: 

sec 

RANGE: [-20,5] 

DATA TYPE: array (1..3, 0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR OUTPUT 
ACCURACY: TBD 

NAME: A BIAS 

DESCRIPTION: characteristic bias in the 
accelerometer measurements 
USED IN: ASP 

meters 

UNITS: 5- 

sec 

RANGE: [-30,0] 

DATATYPE: array (1..3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: A_COUNTER 

DESCRIPTION: accelerations along the X , y , and 
Z axes 

USED IN: ASP 
UNITS: none 
RANGE: [0, 2 15 -1] 

DATA TYPE: array (1.. 3) of Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: A_GAIN_0 

DESCRIPTION: standard gain in the accelerations 
USED IN: ASP 

meters 

UNITS: 7- 

sec 

RANGE: [0, 1] 

DATATYPE: array (1..3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: A SCALE 

DESCRIPTION: multiplicative constant used to 
determine limit on deviation accelerometer values. 
USED IN: ASP 
UNITS: none 
RANGE: [0,3] 

DATA TYPE: Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: A_STATUS 

DESCRIPTION: Flag indicating whether or not the 
accelerometers are working properly. 

USED IN: ASP, CP 
UNITS: none 

RANGE: [0 : healthy, 1: unhealthy] 

DATA TYPE: array (1..3, 0..3) of logicaUl 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCESTATE 
ACCURACY: N/A 

NAME: AECLP DONE 

DESCRIPTION: Flag indicating completion of 

AECLP task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task AECLP 

incomplete, TRUE: running of task AECLP complete] 

DATATYPE: logicaUl 

ATTRIBUTE: control 

DATA STORE LOCATION: none 

ACCURACY: N/A 

NAME: AE CMD 

DESCRIPTION: Valve settings for the axial engines. 
USED IN: AECLP, CP 
UNITS: none 
RANGE: [0, 127] 

DATATYPE: array (1..3) of Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: TBD 

NAME: AE_STATUS 
DESCRIPTION: Status of axial engines. 

USED IN: AECLP, CP 
UNITS: none 

RANGE: [0: Healthy, 1: Failed.] 

DATATYPE: logicaUl 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: AE SWITCH 

DESCRIPTION: Flag indicating whether or not axial 
engines are turned on. 

USED IN: AECLP, GP 
UNITS: none 

RANGE: [0: axial engines are off, 1: axial engines are 
on.] 

DATATYPE: logicaUl 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE STATE 

ACCURACY: N/A 
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NAME: AETEMP 

DESCRIPTION: Temperature of axial engines when 
they are turned on. 

USED IN: AECLP, CP, CRCP, GP 
UNITS: none 

RANGE: [0: Cold, 1: Warming-Up, 2: Hot] 

DATA TYPE: Integer*! 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE STATE 

ACCURACY: N/A 

NAME: ALPHA MATRIX 

DESCRIPTION: Matrix of misalignment angles 

USED IN: ASP 

UNITS: none 

RANGE: [-7T, 7T] 

DATATYPE: array (1.. 3, 1..3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: AR ALTITUDE 

DESCRIPTION: altimeter radar height above terrain 
USED IN: ARSP, CP, GP 
UNITS: meters 
RANGE: [0,2000] 

DATA TYPE: array (0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR OUTPUT 
ACCURACY: TBD 

NAME: AR COUNTER 

DESCRIPTION: counter containing elapsed time 

since transmission of radar pulse 

USED IN: ARSP 

UNITS: Cycles 

RANGE: [-1, 2 15 -1] 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: AR FREQUENCY 
DESCRIPTION: increment frequency of 
ARCOUNTER 
USED IN: ARSP 


sec 

RANGE: [l,2.45xl0 9 ] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: AR STATUS 
DESCRIPTION: status of the altimeter radars 
USED IN: ARSP, CP 
UNITS: none 

RANGE: [0 : healthy, 1: failed] 

DATATYPE: array (0.. 4) of logical* 1 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: ARSP DONE 

DESCRIPTION: Flag indicating completion of ARSP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task ARSP incomplete, 
TRUE: running of task ARSP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: ASP DONE 

DESCRIPTION: Flag indicating completion of ASP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task ASP incomplete, 
TRUE: running of task ASP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: ATMOSPHERIC TEMP 
DESCRIPTION: atmospheric temperature 
USED IN: ASP, CP, GSP, TSP 
UNITS: degrees C 
RANGE: [-200,25] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR OUTPUT 
ACCURACY: TBD 

NAME: C_STATUS 

DESCRIPTION: Flag indicating whether or not the 
communications processor is working properly. 

USED IN: CP 
UNITS: none 

RANGE: [0: healthy, 1: failed] 

DATATYPE: logical*l 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 
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NAME: CHUTE RELEASED 

DESCRIPTION: signal indicating parachute has been 

released 

USED IN: AECLP, CP, CRCP, GP 
UNITS: none 

RANGE: [0: Chute Attached, 1: Chute Released] 
DATATYPE: logical*l 
ATTRIBUTE: data condition 
DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: CL 

DESCRIPTION: Index which specifies which set of 
Control Law Parameters to use 
USED IN: AECLP, GP 
UNITS: none 

RANGE: [1: first, 2: second] 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: CLP DONE 

DESCRIPTION: Control signal which indicates 
whether or not Control Law Processing function has 
completed. 

USED IN: 2. RUNGCS 
UNITS: none 

RANGE: [FALSE: running of Control Law 
Processing function incomplete, TRUE: running of 
Control Law Processing function complete] 
DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: COMM SYNC PATTERN 
DESCRIPTION: sixteen bit synchronization pattern 
USED IN: CP 
UNITS: none 

RANGE: [1101100110110010] (binary) 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: CONTOUR ALTITUDE 

DESCRIPTION: Altitude in velocity-altitude contour. 

USED IN: GP 

UNITS: kilometers 

RANGE: [-.01,2] 

DATATYPE: array (1.. 100) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: CONTOUR CROSSED 
DESCRIPTION: Indicates if the velocity-altitude 
contour has been sensed. 

USED IN: AECLP, CP, GP 
UNITS: none 

RANGE: [0: contour not crossed, 1: contour crossed] 


DATATYPE: logical*l 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE STATE 

ACCURACY: N/A 

NAME: CONTOUR VELOCITY 
DESCRIPTION: Velocity in velocity-altitude 
contour. 

USED IN: GP 

kilometers 

UNITS: 

sec 

RANGE: [0,0.5] 

DATATYPE: array (1.. 100) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: CP DONE 

DESCRIPTION: Flag indicating completion of CP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task CP incomplete, 
TRUE: running of task CP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: CRCP DONE 

DESCRIPTION: Flag indicating completion of CRCP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task CRCP incomplete, 
TRUE: running of task CRCP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: DELTA_T 
DESCRIPTION: Time step duration. 

USED IN: AECLP, GP, RECLP, TDLRSP 
UNITS: seconds 
RANGE: [0.005,0.20] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: DROP HEIGHT 

DESCRIPTION: Height from which vehicle should 

free-fall to surface 

USED IN: GP 

UNITS: meters 

RANGE: [0, 100] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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NAME: DROP SPEED 

DESCRIPTION: Optimal speed during constant 
velocity descent. 

USED IN: GP 

meters 

UNITS: 

sec 

RANGE: [0,4.0] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: ENGINES_ON ALTITUDE 
DESCRIPTION: Altitude at which the axial engines 
are turned on. 

USED IN: AECLP, GP 
UNITS: meters 
RANGE: [0,2000] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: FRAME BEAM UNLOCKED 
DESCRIPTION: Variable containing the number of 
the frame during which the radar beam unlocked 
USED IN: TDLRSP 
UNITS: none 
RANGE: [0, 2 31 -1] 

DATATYPE: array (1..4) of Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCESTATE 
ACCURACY: TBD 

NAME: FRAME COUNTER 

DESCRIPTION: Counter containing the number of 

the present frame 

USED IN: AECLP, ARSP, CP, GP, TDLRSP 
UNITS: none 
RANGE: [1,2 31 -1] 

DATA TYPE: Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: FRAME ENGINES IGNITED 
DESCRIPTION: Variable containing the number of 
the frame during which the engines were ignited 
USED IN: AECLP, GP 
UNITS: none 
RANGE: [0, 2 31 -1] 

DATA TYPE: Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: FULL UP_TIME 

DESCRIPTION: Time for axial engines to reach 

optimum operational condition 

USED IN: AECLP 

UNITS: seconds 


RANGE: [0,60] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: G1 

DESCRIPTION: coefficient used to adjust A GAIN 
USED IN: ASP 

meters 


UNITS: — — 

deg reeC 

RANGE: [-5,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: G2 

DESCRIPTION: coefficient used to adjust A_GAIN 
USED IN: ASP 


meters 
„ 2 


UNITS: 


deg reeC 
RANGE: [-5,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: G3 

DESCRIPTION: coefficient used to adjust G_GAIN 
USED IN: GSP 

radians 


UNITS: , 

deg reeC 

RANGE: [-5,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


A-86 



NAME: G4 

DESCRIPTION: coefficient used to adjust G_GAIN 
USED IN: GSP 

radians 

UNITS: ^ — ~ 

deg ree C 

RANGE: [-5, 5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: G COUNTER 

DESCRIPTION: gyroscope measurement of vehicle 
rotation rates 
USED IN: GSP 
UNITS: none 

RANGE: [-(2 14 -1), 2 14 -1] 

DATATYPE: array (1..3) of Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 


NAME: G GAIN O 

DESCRIPTION: standard gain in vehicle rotation 
rates as measured by the gyroscopes 
USED IN: GSP 


UNITS: 


radians 

sec 


RANGE: [-1, 1] 

DATATYPE: array (1..3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: G OFFSET 

DESCRIPTION: standard offset of the rotation raw 
values 


USED IN: GSP 

radians 

UNITS: 

sec 

RANGE: [-0.5, 0.5] 

DATATYPE: array (1..3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: G ROTATION 
DESCRIPTION: vehicle rotation rates 


USED IN: CP, GSP, GP, RECLP 

radians 

UNITS: 

sec 

RANGE: [-1.0, 1.0] 

DATA TYPE: array (1..3, 0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR OUTPUT 
ACCURACY: TBD 


NAME: G_STATUS 
DESCRIPTION: status of the gyroscopes 
USED IN: CP, GSP 
UNITS: none 

RANGE: [0 : healthy, 1: failed] 

DATATYPE: logicaUl 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: GA 
DESCRIPTION: gain 
USED IN: AECLP 
sec 

UNITS: 

meter 
RANGE: [0,50] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GAX 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: none 
RANGE: [0,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GP1 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: none 
RANGE: [-5,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GP2 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: none 
RANGE: [-5,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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NAME: GP ALTITUDE 

DESCRIPTION: altitude as seen by guidance 

processor 

USED IN: AECLP, CP, GP 
UNITS: meters 
RANGE: [0,2000] 

DATA TYPE: array (0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: GP ATTITUDE 
DESCRIPTION: direction cosine matrix 
USED IN: AECLP, CP, GP 
UNITS: none 
RANGE: [-1, 1] 

DATATYPE: array (1.. 3, 1..3, 0..4) real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: GP DONE 

DESCRIPTION: Flag indicating completion of GP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task GP incomplete, 
TRUE: running of task GP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME: GP VELOCITY 
DESCRIPTION: Velocity as corrected by the 
guidance algorithm. 

USED IN: AECLP, CP, GP 

meters 

UNITS: 

sec 

RANGE: [-100, 100] 

DATATYPE: array ( 1..3, 0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: GPY 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: none 
RANGE: [-5,5] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GQ 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: seconds 
RANGE: [-5,8] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: GP PHASE 

DESCRIPTION: phase of operation as seen by 

guidance processor 

USED IN: CP, GP 

UNITS: none 

RANGE: [1,5] 

DATA TYPE: integer*4 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE STATE 

ACCURACY: TBD 


NAME: GP ROTATION 


DESCRIPTION: rotation rates as determined by the 
guidance processing functional unit 
USED IN: AECLP, CP, GP 
radians 


UNITS: 


sec 

RANGE: [-1.0, 1.0] 

DATATYPE: array (1..3, 1..3) real*8 


ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 


NAME: GR 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: seconds 
RANGE: [-5,8] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GRAVITY 
DESCRIPTION: gravity of planet 
USED IN: AECLP, GP 

meters 

UNITS: — 

sec 

RANGE: [0, 100] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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NAME: GSP DONE 

DESCRIPTION: Flag indicating completion of GSP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task GSP incomplete, 
TRUE: running of task GSP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: GV 
DESCRIPTION: gain 
USED IN: AECLP 
sec 

UNITS: 

meter 

RANGE: [-5,8] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GVE 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: /second 
RANGE: [0,500] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GVEI 
DESCRIPTION: gain 
USED IN: AECLP 

UNITS: /second 2 
RANGE: [-5,40] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GVI 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: /meter 
RANGE: [-5,5] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: GW 
DESCRIPTION: gain 
USED IN: AECLP 
sec 

UNITS: 

meter 
RANGE: [-5,8] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: GWI 
DESCRIPTION: gain 
USED IN: AECLP 
UNITS: /meter 
RANGE: [-5,5] 

DATATYPE: array (1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: INITDONE 

DESCRIPTION: Flag indicating completion of GCS 
initialization. 

USED IN: 0. GCS 
UNITS: none 

RANGE: [FALSE: initialization incomplete, TRUE: 
initialization complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: INTERN AL CMD 

DESCRIPTION: Real vector containing the command 

to be sent to the axial engines 

USED IN: AECLP 

UNITS: none 

RANGE: [-0.7, 1.7] 

DATATYPE: array (1..3) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE_STATE 
ACCURACY: TBD 

NAME: K ALT 

DESCRIPTION: Determines use of altimeter radar by 

guidance processor 

USED IN: ARSP, CP, GP 

UNITS: none 

RANGE: [0, 1] 

DATATYPE: array (0..4) of Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 
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NAME: K MATRIX 

DESCRIPTION: Determines use of doppler radar by 
guidance processor. 

USED IN: CP, GP, TDLRSP 
UNITS: none 
RANGE: [0, 1] 

DATATYPE: array (1.. 3, 1..3, 0..4) Integer*4 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: Ml 

DESCRIPTION: lower measured temperature 
calibration point for solid state temperature sensor 
USED IN: TSP 
UNITS: none 
RANGE: [0, 2 15 -1] 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: MAX NORM AL VELOCITY 
DESCRIPTION: Maximum vertical 
velocity for safe landing 
USED IN: GP 

meters 

UNITS: 

sec 

RANGE: [0,3.35] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: OMEGA 

DESCRIPTION: gain of angular velocity 
USED IN: AECLP 
UNITS: /second 
RANGE: [-50,50] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: M2 

DESCRIPTION: upper measured temperature 
calibration point for solid state temperature sensor 
USED IN: TSP 
UNITS: none 
RANGE: [0, 2 15 -1] 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: PI 


DESCRIPTION: pulse rate boundary 
USED IN: RECLP 


UNITS: 


radians 

sec 


RANGE: [0,0.05] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: M3 

DESCRIPTION: lower measured temperature 
calibration point for thermocouple pair temperature 
sensor 

USED IN: TSP 
UNITS: none 
RANGE: [0, 2 15 -1] 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: M4 

DESCRIPTION: upper measured temperature 
calibration point for thermocouple pair temperature 
sensor 

USED IN: TSP 
UNITS: none 
RANGE: [0, 2 15 -1] 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: P2 


DESCRIPTION: pulse rate boundary 
USED IN: RECLP 


UNITS: 


radians 

sec 


RANGE: [0,0.05] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: P3 


DESCRIPTION: pulse rate boundary 
USED IN: RECLP 


UNITS: 


radians 

sec 


RANGE: [0,0.05] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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NAME: P4 


DESCRIPTION: pulse rate boundary 
USED IN: RE CLP 


UNITS: 


radians 

sec 


RANGE: [0,0.05] 
DATATYPE: real*8 


ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: PACKET 

DESCRIPTION: Packet of telemetry data 
USED IN: CP 
UNITS: N/A 
RANGE: N/A 

DATA TYPE: array (1.. 256) of Integer*! 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 


NAME: PE INTEGRAL 

DESCRIPTION: Integral portion of Pitch error 

equation 

USED IN: AECLP, CP 
UNITS: meters 
RANGE: [-100, 100] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 


NAME: RE CMD 

DESCRIPTION: roll engine command 
USED IN: CP, RECLP 
UNITS: none 
RANGE: 

[1 : off, 

2: minimum, counterclockwise, 

3: minimum, clockwise, 

4; intennediate, counterclockwise, 

5: intennediate, clockwise, 

6: maximum, counterclockwise, 

7: maximum, clockwise] 

note: the values above for Range have been derived 
from range of intensity and direction as follows: 
Intensity [00:off, Olmiinimum, 10:intermediate, 

1 1 maximum] (binary) 

Direction [0:counterclockwise (positive), 

1 xlockwise (negative)] (binary) 

DATA TYPE: Integer*! 

ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: TBD 

NAME: RE STATUS 
DESCRIPTION: status of the roll engines 
USED IN: CP, RECLP 
UNITS: none 

RANGE: [0 : healthy, 1: failed] 

DATATYPE: logical*l 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 


NAME: PE MAX 

DESCRIPTION: Maximum pitch error tolerable 
USED IN: AECLP 
UNITS: none 
RANGE: [0, 1] 

DATATYPE: array(1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: PEMIN 

DESCRIPTION: Minimum pitch error tolerable. 
USED IN: AECLP 
UNITS: none 
RANGE: [-1,0] 

DATATYPE: array(1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: RE SWITCH 

DESCRIPTION: Flag indicating whether or not the 
roll engines are turned on. 

USEDlN: GP, RECLP 
UNITS: none 

RANGE: [0: roll engines are off, 1: roll engines are 
on.] 

DATATYPE: logical*l 

ATTRIBUTE: data condition 

DATA STORE LOCATION: GUIDANCE_STATE 

ACCURACY: N/A 

NAME: RECLP DONE 

DESCRIPTION: Flag indicating completion of 

RECLP task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task RECLP 

incomplete, TRUE: running of task RECLP complete] 

DATATYPE: logical* 1 

ATTRIBUTE: control 

DATA STORE LOCATION: none 

ACCURACY: N/A 
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NAME: RENDEZVOUS 
DESCRIPTION: Control signal which indicates 
whether or not GCS_SIM_RENDEZVOUS is to be 
activated. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: GCS_SIM RENDEZVOUS is not 
to be activated, TRUE: GCS_SIM RENDEZVOUS is 
to be activated] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: RUN DONE 

DESCRIPTION: Flag indicating completion of GCS. 
USED IN: 0. GCS 
UNITS: none 

RANGE: [FALSE: running of GCS incomplete, 
TRUE: running of GCS complete] 

DATATYPE: logicaUl 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: SP DONE 

DESCRIPTION: Control signal which indicates 
whether or not Sensor Processing function has been 
completed. 

USED IN: 2. RUN_GCS 
UNITS: none 

RANGE: [FALSE: running of Sensor Processing 
function incomplete, TRUE: running of Sensor 
Processing function complete] 

DATATYPE: logicaUl 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: SS_TEMP 

DESCRIPTION: Solid state temperature data 
USED IN: TSP 
UNITS: none 
RANGE: [0, 2 15 -1] 

DATA TYPE: Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 


NAME: SUBFRAME_COUNTER 
DESCRIPTION: Counter containing the number of 
the present subframe. 

USED IN: CP 
UNITS: none 
RANGE: [1,3] 

DATA TYPE: Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: T1 

DESCRIPTION: lower ambient temperature 
calibration point for solid state temperature sensor 
USED IN: TSP 
UNITS: degrees C 
RANGE: [-250,250] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: T2 

DESCRIPTION: upper ambient temperature 
calibration point for solid state temperature sensor 
USED IN: TSP 
UNITS: degrees C 
RANGE: [-250,250] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: T3 

DESCRIPTION: lower ambient temperature 
calibration point for thermocouple pair temperature 
sensor 

USED IN: TSP 
UNITS: degrees C 
RANGE: [-50,50] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: T4 

DESCRIPTION: upper ambient temperature 
calibration point for thermocouple pair temperature 
sensor 

USED IN: TSP 
UNITS: degrees C 
RANGE: [-50,50] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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NAME: TD COUNTER 

DESCRIPTION: value returned by Touch Down 

Sensor 

USED IN: TDSP 
UNITS: none 
RANGE: [-2 15 ,2 15 -1] 

DATA TYPE: Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: TD SENSED 

DESCRIPTION: Flag indicating whether or not touch 
down has been sensed. 

USED IN: CP, GP. TDSP 
UNITS: none 

RANGE: [0: touch down not sensed, 1: touch down 
sensed] 

DATATYPE: logicaUl 

ATTRIBUTE: data condition 

DATA STORE LOCATION: SENSOR OUTPUT 

ACCURACY: N/A 

NAME: TDLR ANGLES 

DESCRIPTION: vector of doppler radar beam offset 
angles (i.e., a , (3, y) 

USED IN: TDLRSP 
UNITS: radians 

RANGE: [0, ~ ) 

2 

DATA TYPE: array (1.. 3) real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: TDLR COUNTER 

DESCRIPTION: value returned by Doppler radar 

USED IN: TDLRSP 

UNITS: none 

RANGE: [0, 2 15 -1] 

DATA TYPE: array (1.. 4) Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 

NAME: TDLR GAIN 
DESCRIPTION: gain in doppler radar beam 
USED IN: TDLRSP 
meters 

UNITS: 

sec 

RANGE: [-1, 1] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: TDLR LOCK TIME 

DESCRIPTION: locking time of doppler radar beam 

USED IN: TDLRSP 

UNITS: seconds 

RANGE: [0,60] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: TDLR OFFSET 
DESCRIPTION: offset in doppler radar beam 
USED IN: TDLRSP 

meters 

UNITS: 

sec 

RANGE: [-100,0] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: TDLR STATE 

DESCRIPTION: state of the touch down landing 
radar beams. 

USED IN: CP, TDLRSP 
UNITS: none 

RANGE: [0: Beam unlocked, 1: Beam locked] 
DATATYPE: array (1..4) logical*l 
ATTRIBUTE: data condition 
DATA STORE LOCATION: GUIDANCE_STATE 
ACCURACY: N/A 

NAME: TDLR STATUS 
DESCRIPTION: status of the doppler radar 
USED IN: CP, TDLRSP 
UNITS: none 

RANGE: [0 : healthy, 1: failed] 

DATATYPE: array (1.. 4) of logical* 1 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: TDLR VELOCITY 

DESCRIPTION: Velocity as computed by the touch 

down landing radar. 

USED IN: CP, GP, TDLRSP 

meters 

UNITS: 

sec 

RANGE: [-100, 100] 

DATA TYPE: array (1.. 3, 0..4) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: SENSOR OUTPUT 
ACCURACY: TBD 
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NAME: TDLRSP DONE 

DESCRIPTION: Flag indicating completion of 

TDLRSP task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task TDLRSP 
incomplete, TRUE: running of task TDLRSP 
complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: TDSP DONE 

DESCRIPTION: Flag indicating completion of TDSP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task TDSP incomplete, 
TRUE: running of task TDSP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 

NAME: TDS_STATUS 

DESCRIPTION: status of the touch down sensor 
USED IN: CP, GP, TDSP 
UNITS: none 

RANGE: [0 : healthy, 1: failed] 

DATATYPE: logicaUl 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: TE DROP 

DESCRIPTION: The axial thrust error when axial 
engines are warm and the velocity altitude contour has 
not been intersected. 

USED IN: AECLP 
UNITS: none 
RANGE: [-2,2] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: TE INIT 

DESCRIPTION: The axial thrust error when the axial 
engines are cold. 

USED IN: AECLP 
UNITS: none 
RANGE: [-2,2] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 


NAME: TE INTEGRAL 

DESCRIPTION: Integral portion of Thrust error 

equation 

USED IN: AECLP, CP, GP 
UNITS: meters 
RANGE: [-100, 100] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: TE LIMIT 
DESCRIPTION: Limiting thrust error 
USED IN: AECLP 
UNITS: none 
RANGE: [-100, 100] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: TE MAX 

DESCRIPTION: Maximum thrust error tolerable 
USED IN: AECLP 
UNITS: none 
RANGE: [-2,2] 

DATATYPE: array(1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: TEMIN 

DESCRIPTION: Minimum thrust error tolerable. 
USED IN: AECLP 
UNITS: none 
RANGE: [-2,2] 

DATATYPE: array(1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: THERMO_TEMP 

DESCRIPTION: thermocouple pair temperature 

USED IN: TSP 

UNITS: none 

RANGE: [0, 2 15 -1] 

DATA TYPE: Integer*2 
ATTRIBUTE: data 

DATA STORE LOCATION: EXTERNAL 
ACCURACY: N/A 
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NAME: THETA 
DESCRIPTION: roll angle 
USED IN: RECLP 
UNITS: radians 
RANGE: [-7T,7r] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: THETA1 

DESCRIPTION: pulse angle boundary 
USED IN: RECLP 
UNITS: radians 
RANGE: [0,0.05] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: THETA2 

DESCRIPTION: pulse angle boundary 
USED IN: RECLP 
UNITS: radians 
RANGE: [0,0.05] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: TS_STATUS 

DESCRIPTION: status of the temperature sensors in 
solid state, then thermocouple pair order 
USED IN: CP, TSP 
UNITS: none 

RANGE: [0 : healthy, 1: failed] 

DATATYPE: array (1.. 2) of logical* 1 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: N/A 

NAME: TSP DONE 

DESCRIPTION: Flag indicating completion of TSP 
task. 

USED IN: 2. RUN GCS 
UNITS: none 

RANGE: [FALSE: running of task TSP incomplete, 
TRUE: running of task TSP complete] 

DATATYPE: logical*l 
ATTRIBUTE: control 
DATA STORE LOCATION: none 
ACCURACY: N/A 


NAME: VELOCITY ERROR 
DESCRIPTION: Distance from velocity-altitude 
contour. (Difference in velocities from actual to 
desired on contour.) 

USED IN: AECLP, CP, GP 

meters 

UNITS: 

sec 

RANGE: [-300,20] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: YE INTEGRAL 

DESCRIPTION: Integral portion of Yaw error 

equation 

USED IN: AECLP, CP 
UNITS: meters 
RANGE: [-100, 100] 

DATATYPE: real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: GUIDANCE STATE 
ACCURACY: TBD 

NAME: YE MAX 

DESCRIPTION: Maximum yaw error tolerable 
USED IN: AECLP 
UNITS: none 
RANGE: [-1, 1] 

DATATYPE: array(1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 

NAME: YEMIN 

DESCRIPTION: Minimum yaw error tolerable. 
USED IN: AECLP 
UNITS: none 
RANGE: [-1, 1] 

DATATYPE: array(1..2) of real*8 
ATTRIBUTE: data 

DATA STORE LOCATION: RUN PARAMETERS 
ACCURACY: N/A 
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PART II. CONTENTS OF DATA STORES 


Table A.6.1 DATA STORE: GUIDANCE STATE 


VARIABLE NAME 

USED BY: 

ASTATUS 

ASP, CP 

AESTATUS 

AECLP, CP 

AESWITCH 

AECLP, GP 

AETEMP 

AECLP, CP, CRCP, GP 

ARSTATUS 

ARSP, CP 

CSTATUS 

CP 

CL 

AECLP, GP 

CONTOURCROSSED 

AECLP, CP, GP 

FRAMEBEAMUNLOCKED 

TDLRSP 

FRAMEENGINESIGNITED 

AECLP, GP 

GSTATUS 

CP, GSP 

GPALTITUDE 

CP, GP, AECLP 

GPATTITUDE 

AECLP, CP, GP 

GPPHASE 

CP, GP 

GPROTATION 

AECLP, CP, GP 

GPVELOCITY 

AECLP, CP, GP 

INTERN ALCMD 

AECLP 

KALT 

ARSP, CP, GP 

KMATRIX 

CP, GP, TDLRSP 

PEINTEGRAL 

AECLP, CP 

RESTATUS 

CP, RECLP 

RESWITCH 

GP, RECLP 

TDLRSTATE 

CP, TDLRSP 

TDLRSTATUS 

CP, TDLRSP 

TDSSTATUS 

CP, GP, TDSP 

TEINTEGRAL 

AECLP, CP, GP 

TELIMIT 

AECLP 

THETA 

RECLP 

TSSTATUS 

CP, TSP 

VELOCITYERROR 

AECLP, CP, GP 

YEINTEGRAL 

AECLP, CP 
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Table A.6.2 DATA STORE: EXTERNAL 


VARIABLE NAME 

USED BY 

ACOUNTER 

ASP 

AECMD 

AECLP, CP 

ARCOUNTER 

ARSP 

CHUTERELEASED 

AECLP, CP, CRCP, GP 

FRAMECOUNTER 

AECLP, ARSP, CP, GP, TDLRSP 

GCOUNTER 

GSP 

PACKET 

CP 

RECMD 

RECLP, CP 

SSTEMP 

TSP 

SUBFRAMECOUNTER 

CP 

TDCOUNTER 

TDSP 

TDLRCOUNTER 

TDLRSP 

T HERMOTEMP 

TSP 


Table A.6.3 DATA STORE: SENSOR_OUTPUT 


VARIABLE NAME 

USED BY: 

AACCELERATION 

ARALTITUDE 

ATMOSPHERICTEMP 

GROTATION 

TDSENSED 

TDLRVELOCITY 

AECLP, ASP, CP, GP 
ARSP, CP, GP 
ASP, CP, GSP, TSP 
CP, GSP, GP, RECLP 
CP, GP, TDSP 
CP, GP, TDLRSP 
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Table A.6.4 DATA STORE: RUN PARAMETERS 


VARIABLE NAME 

USED BY 

A BIAS 

ASP 

A GAIN 0 

ASP 

A SCALE 

ASP 

ALPHA MATRIX 

ASP 

AR FREQUENCY 

ARSP 

COMM SYNC PATTERN 

CP 

CONTOUR ALTITUDE 

GP 

CONTOUR VELOCITY 

GP 

DELTA T 

AECLP, GP, RECLP, TDLRSP 

DROP HEIGHT 

GP 

DROP SPEED 

GP 

ENGINES ON ALTITUDE 

AECLP, GP 

FULL UP TIME 

AECLP 

G1 

ASP 

G2 

ASP 

G3 

GSP 

G4 

GSP 

G GAIN 0 

GSP 

G OFFSET 

GSP 

GA 

AECLP 

GAX 

AECLP 

GP1 

AECLP 

GP2 

AECLP 

GPY 

AECLP 

GQ 

AECLP 

GR 

AECLP 

GRAVITY 

AECLP, GP 

GV 

AECLP 

GVE 

AECLP 

GVEI 

AECLP 

GVI 

AECLP 

GW 

AECLP 

GWI 

AECLP 

Ml 

TSP 

M2 

TSP 

M3 

TSP 

M4 

TSP 

MAX NORMAL VELOCITY 

GP 

OMEGA 

AECLP 

PI 

RECLP 

P2 

RECLP 

P3 

RECLP 

P4 

RECLP 

PE MAX 

AECLP 

PE MIN 

AECLP 

T1 

TSP 

T2 

TSP 

T3 

TSP 

T4 

TSP 
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Table A.6.4 (continued) DATA STORE: RUNPARAMETERS 


VARIABLE NAME 

USED BY 

TDLRANGLES 

TDLRSP 

TDLRGAIN 

TDLRSP 

T DLRLOCKTIME 

TDLRSP 

TDLROFFSET 

TDLRSP 

TEDROP 

AECLP 

TEINIT 

AECLP 

TEMAX 

AECLP 

TEM1N 

AECLP 

THETA1 

RECLP 

THETA2 

RECLP 

YEMAX 

AECLP 

YE MIN 

AECLP 
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PART III. CONTROL SIGNALS, DATA CONDITIONS, AND GROUP FLOWS 


Table A.6.5 CONTROL SIGNALS (OPTIONAL USAGE) 


CONTROL SIGNAL NAME 
AECLPDONE 
ARSPDONE 
ASPDONE 
CLPDONE 
CPDONE 
CRCPDONE 
GPDONE 
GSPDONE 
INITDONE 
RECLPDONE 
RENDEZVOUS 
RUNDONE 
SPDONE 
TDLRSPDONE 
TDSPDONE 
TSP DONE 


Note: These variables are not in the required global data stores. 


Table A.6.6 DATA CONDITIONS (REQUIRED USAGE) 


DATA CONDITION VARIABLE NAME 
AES WITCH 
AETEMP 
CHUTERELEASED 
CONTOURCROSSED 
GPPHASE 
RESWITCH 
TDSENSED 
TDLR STATE 
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Table A.6.7 INITIALIZATION DATA 


VARIABLE NAME 

USED BY 

A ACCELERATION 

AECLP, ASP, CP, GP 

A BIAS 

ASP 

A COUNTER 

ASP 

A GAIN 0 

ASP 

A SCALE 

ASP 

A STATUS 

ASP, CP 

AE STATUS 

AECLP, CP 

AE SWITCH 

AECLP, GP 

AE TEMP 

AECLP, CP, CRCP, GP 

ALPHA MATRIX 

ASP 

AR ALTITUDE 

ARSP, CP, GP 

AR COUNTER 

ARSP 

AR FREQUENCY 

ARSP 

AR STATUS 

ARSP, CP 

ATMOSPHERIC TEMP 

ASP, CP, GSP, TSP 

C STATUS 

CP 

CHUTE RELEASED 

AECLP, CP, CRCP, GP 

CL 

AECLP, GP 

COMM SYNC PATTERN 

CP 

CONTOUR ALTITUDE 

GP 

CONTOUR CROSSED 

AECLP, CP, GP 

CONTOUR VELOCITY 

GP 

DELTA T 

AECLP, GP, RECLP, TDLRSP 

DROP HEIGHT 

GP 

DROP SPEED 

GP 

ENGINES ON ALTITUDE 

AECLP, GP 

FRAME BEAM UNLOCKED 

TDLRSP 

FRAME COUNTER 

AECLP, ARSP, CP, GP, TDLRSP 

FRAME ENGINES IGNITED 

AECLP, GP 

FULL UP TIME 

AECLP 

G1 

ASP 

G2 

ASP 

G3 

GSP 

G4 

GSP 

G COUNTER 

GSP 

G GAIN 0 

GSP 

G OFFSET 

GSP 

G ROTATION 

CP, GSP, GP, RECLP 

G STATUS 

CP, GSP 

GA 

AECLP 

GAX 

AECLP 

GP1 

AECLP 

GP2 

AECLP 

GP ALTITUDE 

AECLP, CP, GP 

GP ATTITUDE 

AECLP, CP, GP 

GP PHASE 

CP, GP 

GP ROTATION 

AECLP, CP, GP 

GP VELOCITY 

AECLP, CP, GP 

GPY 

AECLP 

GQ 

AECLP 

GR 

AECLP 

GRAVITY 

AECLP, GP 

GV 

AECLP 
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Table A.6.7 (continued) INITIALIZATION DATA 


VARIABLE NAME 

GVE 

GVEI 

GVI 

GW 

GWI 

K ALT 

KMATRIX 

Ml 

M2 

M3 

M4 

MAXNORMALVELOCITY 

OMEGA 

PI 

P2 

P3 

P4 

PEINTEGRAL 

PEMAX 

PEMIN 

RESTATUS 

RESWITCH 

SSTEMP 

SUBFRAMECOUNTER 

T1 

T2 

T3 

T4 

TDCOUNTER 

TDSENSED 

TDLRANGLES 

TDLRCOUNTER 

TDLRGAIN 

T DLRLOCKTIME 

TDLROFFSET 

TDLRSTATE 

TDLRSTATUS 

T DLRVELOCIT Y 

TDSSTATUS 

TEDROP 

TEINIT 

TEINTEGRAL 

TELIMIT 

TEMAX 

TEMIN 

T HERMOTEMP 

THETA 

THETA1 

THETA2 

TSSTATUS 

VELOCITYERROR 

YEINTEGRAL 


USED BY 

' AECLP 
AECLP 
AECLP 
AECLP 
AECLP 
ARSP, CP, GP 
CP, GP, TDLRSP 
TSP 
TSP 
TSP 
TSP 
GP 

AECLP 

RECLP 

RECLP 

RECLP 

RECLP 

AECLP, CP 

AECLP 

AECLP 

CP, RECLP 

GP, RECLP 

TSP 

CP 

TSP 

TSP 

TSP 

TSP 

TDSP 

CP, GP, TDSP 
TDLRSP 
TDLRSP 
TDLRSP 
TDLRSP 
TDLRSP 
CP, TDLRSP 
CP, TDLRSP 
CP, GP, TDLRSP 
CP, GP, TDSP 
AECLP 
AECLP 

AECLP, CP, GP 

AECLP 

AECLP 

AECLP 

TSP 

RECLP 

RECLP 

RECLP 

CP, TSP 

AECLP, CP, GP 

AECLP, CP 
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YEMAX 
YE MIN 


AECLP 

AECLP 


Table A.6.8 TEMPDATA 

VARIABLE NAME 
SSTEMP 
THERMO TEMP 


Table A.6.9 SEN SORDATA 

VARIABLE NAME 
ACOUNTER 
ARCOUNTER 
TDLRCOUNTER 
GCOUNTER 
TEMPDATA 
TD COUNTER 


Table A.6. 10 OUTPUT DATA 

VARIABLE NAME 
AECMD 
RECMD 
PACKET 


Table A.6. 1 1 OUTPUT CONTROL 

VARIABLE NAME 
AESWITCH 
RESWITCH 
CHUTERELEASED 


Table A.6. 12 FRAME DATA 

VARIABLE NAME 
FRAMECOUNTER 
SUBFRAMECOUNTER 

A.7 NOTATION FOR LEVELS 0, 1, 2, AND 3 SPECIFICATION 
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This specification was developed using the extended structured analysis method 
advocated by Hatley (ref. A. 12, A. 13) and Cadre's teamwork (ref. A. 19). This method is 
based on a hierarchical approach to defining processes and the associated data and 
control flows. 

The documents constructed as a part of this specification include data context and 
flow diagrams, control context and flow diagrams, process and control specifications, and 
a Data Requirements Dictionary. Figure A. 7.1 defines the graphical symbols used in the 
data flow and control flow diagrams, respectively. 

The data flow diagrams describe the processes, data flows, and data stores. The 
data context diagram is the highest-level data flow diagram and represents the data flow 
between the system and the external entities. 

The control flow diagrams describe processes, control signal and data condition 
flows, control specifications, and data stores. The control signal and data condition flows 
are depicted using directed arcs with broken lines. The control signals listed in the data 
dictionary may be implemented by the programmer in any form desired, or they may be 
completely ignored and the control of the program conducted through other means. The 
control flow diagrams show what the process structure must do under all conditions. 
Signal flows between the control flow diagram and the control specification have a short 
bar at the end of the directed arc. The control flow diagrams contain duplicate 
descriptions of the processes represented on the data flow diagrams. The control context 
diagram representing the most abstract control flow is similar to the data context diagram. 

The control specifications describe the control requirements of a system. These 
specifications contain the conditions under which the processes detailed in the data and 
control flow diagrams are activated and de-activated, and in some cases also contain 
output values for control signals. 

The Data Requirements Dictionary contains definitions for data, data conditions, 
control signals, and group flows. 

Following is a list of definitions and explanations for the structured analysis 
diagrams: 

1 . The data and control flow names on the directed arcs in the structured analysis figures 
can be found in the Data Requirements Dictionary Part I, while the group flow names 
on the arcs can be found in the Data Requirements Dictionary Part III. 

2. In the Process Activation Tables, the first column contains the inputs. The second set 

of columns (separated by two vertical lines) contains the cells which indicate whether a 

process is to be activated or deactivated. A blank cell indicates that the process is 

deactivated. An integer indicates that the process is activated. A process whose cell 
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contains the integer "n" must complete before the process with integer "n+1" is 
activated. All processes whose cells contain the same integer can be activated in any 
order. The third set of columns, if present, represents the output values for control 
signals. 

3. The meanings for the symbols used in the expressions for inputs are: 

= equal 

~= not equal 

~ logical NOT 

& logical AND 

logical OR 

() grouping (expression inside parentheses is 

evaluated first) 


Figure A.7.1 GRAPHICAL SYMBOLS USED IN STRUCTURED ANALYSIS DIAGRAMS 

PROCESS MODULE 


SOURCE OR SINK 



DATA STORE 


DATA CONDITION OR 
CONTROL FLOW 



> 

> 


CONTROL SPECIFICATION 


► DATA FLOW 

A.8 IMPLEMENTATION NOTES 

INTERFACE 

Background 
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For the purposes of this research experiment, each GCS implementation must 
function as if it were actually controlling a planetary lander. In reality, each GCS 
implementation will be interacting with a software simulator (GCSSIM) that models the 
behavior of a physical lander when exposed to the environmental forces of a planet. 

Due to the fact that each GCS implementation must interact with GCS SIM as if it 
were connected to the lander hardware, there are some additional requirements that are 
placed on a GCS implementation that help define a software interface. The software 
interface to the simulator replaces the physical connection to planetary lander hardware 
through the use of a simulator support utility and an additional requirement involving the 
organization of the global data stores. 

Simulator Support Utility 

A single simulator support utility (GCS SIM RENDEZVOUS) is provided to form 
a uniform interface between the GCS implementation and the simulation environment 
(GCS SIM). This utility is a routine which simplifies the interface between the GCS 
implementations and the simulation of the vehicle sensing and control mechanisms. This 
utility also includes a synchronization mechanism for the configurations using more than 
one version of the GCS. This routine provides the following support functions: 

• Initialization for the Beginning of Terminal Descent 

• Simulator Rendezvous Synchronization 

• GCS Interface for Simulated Reads and Writes 


Input/Output 

The GCS SIM RENDEZVOUS routine simulates all of the input/output operations 
for each GCS implementation. When using the rendezvous routine with a GCS 
implementation, all data needed by rendezvous is passed via the four global data stores 
and there are no additional parameters required. All information read from or written to 
each GCS implementation will be transferred through the four global data stores defined 
in the data dictionary. 
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Figure A.8.1 DIAGRAM OF STORAGE AS SEEN BY GCS IMPLEMENTATIONS 
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Process 

The GCS uses the sensor input values in order to calculate control commands which 
are used by GCSSIM to manipulate the actuators. Since GCSSIM handles the orbit to 
terminal descent portion of each trajectory, a rendezvous must be issued at the start of 
each trajectory to load initial sensor values into each GCS implementation. Following 
the first call to rendezvous, all GCS implementations will synchronize themselves by 
calling rendezvous prior to the execution of each subframe. This rendezvous, in effect, 
suspends the GCS implementations until the other GCS implementations have processed 
this subframe. 

The calling convention for this GCS SIM provided support utility is as follows: 

• GCSSIMRENDEZVOUS ( requires no parameters) 

GCS Initialization 

During the initialization phase of each GCS trajectory (the first call to 
GCS SIM RENDEZVOUS) the frame counter (FRAME COUNTER) will be updated 
with the starting frame number for the particular trajectory, and the subframe counter 
(SUBFRAME_COUNTER) will be initialized to the value one. Under normal 
circumstances, the value of the frame counter will be "1," but the programmer should not 
rely on that. 

By using the interface described above, the simulator can be transparent to the 
implementation. 

A.9 NUMERICAL INTEGRATION INSTRUCTIONS 

Within the Guidance Processing functional unit, the calculations of GPVELOCITY, 
GP ALTITUDE, and GP ATTITUDE require the use of a highly accurate integration method. To 
maintain the necessary degree of accuracy, three methods of numerical integration have been designated as 
acceptable for coding, namely Adams-Moulton method, Hamming's method, and the Runge-Kutta 
fourth-order method for simultaneous equations. If the Runge-Kutta method is used, it is required that the 
three equations be solved as a set of simultaneous equations. 

Each method is briefly described in the following paragraphs, and references to numerical analysis 
texts describing the method are provided. Algorithms specified in either a text listed or another suitable 
numerical analysis text should be used during coding. 


Adams-Moulton Method 
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The Adams-Moulton Method requires values from the previous four time steps to calculate 
the value at the next time step. The Adams-Moulton method is a predictor/corrector method. 
Both (ref. A. 14) (pp. 346-7) and (ref. A. 16) (pp. 478-81) explain the Adams-Moulton method. 

Hamming's Method 

The Hamming method uses a predictor/corrector method similar to that of Adams-Moulton. 
Hamming's method uses the same predictor as Milne's, but uses a much simpler corrector 
formula. Milne's method of integration was deemed too unstable for use, but Hamming's 
method with the simpler corrector is sufficiently stable. A description of both Hamming's 
method and Milne's method can be found in (ref. A. 14) (pp. 347-8). 

Runge-Kutta Fourth-Order Method for Simultaneous Equations 

The well-known Runge-Kutta fourth-order method for simultaneous equations requires only 
the previous two values to calculate the next value. References can be found in many texts 
including: (ref. A.15)(pp. 356-60), (ref. A.17) (pp. 240-6; pp. 282-5), (ref. A.18) (pg. 447; pp. 
471-3) 

During the first time step, using a numerical integration method necessitates some 
specification of previous values. These values will be provided during initialization for 
the data elements provided in Table A. 9. 1 . 
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TABLE A. 9. 1 INITIAL VALUES PROVIDED FOR USE IN INTEGRATION 


A_ ACCELERATION (1..3, 0..4) 
AR_ ALTITUDE (0..4) 

GP ALTITUDE (0..4) 

G P_ ATTITUDE (1..3, 1..3. 0..4) 
GP_ VELOCITY (1..3, 0..4) 

G ROTATION (1..3, 0..4) 

K ALT (0..4) 

K MATR1X (1..3, 1..3, 0..4) 
TDLR VELOCITY (1..3, 0..4) 


Note that not all integration required by the GCS specification requires the use of 
one of the methods listed in this appendix. More specifically, in computing THETA, 
TEINTEGRAL, PEINTEGRAL, and YE INTEGRAL, Euler’s method provides 
sufficient accuracy and simplicity and should be used. Information on Euler's method 
may be found in: (ref. A.14)(pp. 318-22), (ref. A.15)(pg. 223), and (ref. A.16)(pp. 462-3). 

ADAPTATION OF RUNGE-KUTTE FOURTH-ORDER METHOD FOR 
SIMULTANEOUS EQUATIONS TO THE GCS SOFTWARE 

In the case where the Runge-Kutte method has been selected for integration in the 

Guidance Processing functional unit, the following gives information on how it is to be 

applied to GCS. The notation and fonnulas presented here are merely one representation 

of the Runge-Kutte method and its adaptation to GCS. The software 

designer/implementer may vary the notation and/or the form of the equations as long as 

the algorithm used is equivalent to the one presented here. 

The Runge-Kutte fourth-order method (for one dependent variable only) can be 

summarized as follows: 

Given: 

Let dy/dx = f(x,y) 

Let h represent the interval between equidistant values of x 
Let the initial values for x and y be x 0 and y 0 respectively 
Let X[ = x 0 + h 
The problem is to estimate y. 

The solution is: 
yi = y 0 + k 

k = 1/6 x (k + 2 x (k + k ) + k ) 
v 1 v 2 3' 4' 


where: 
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kj = h x f(x Q , y Q ) 

k 2 = h x f(x 0 + h/2, y Q + k/2) 
k 3 = h x f(x Q + h/2, y Q + k/2) 

k 4 = hxf ( x o + h ’ y 0 + k 3> 


The GCS problem to be solved is as follows: 

Simultaneously calculate current values for the variables GPATTITUDE, 
GPVELOCITY, and GP ALT1TUDE, using the equations for the corresponding 
derivatives given in GUIDANCE PROCESSING (P-Spec 2.2), Table A.5.8. 


Adaptation to GCS of the Runge-Kutte fourth-order method for simultaneous equations 

In the discussion that follows, let the "dependent" variables refer to 
GP ATTITUDE, GPVELOCITY, and GP ALTITUDE, and let the "sensor" variables 
refer to G ROTATION, A ACCELERATION, K MATRIX, TDLR VELOCITY, 
K ALT, and ARALTITUDE. In the Runge-Kutte method, it is assumed that the 
derivative for y can be obtained as a function of the dependent and independent variables. 
In GCS, the derivative for each of the dependent variables is a function of some subset of 
the dependent variables and some subset of the sensor variables. The values for the 
sensor variables are only available to GCS at discrete values of time, namely at any time 
which is an integer multiple of the value of DELTA T. It is therefore not possible to 
calculate derivatives at the midpoint between two frames. The mapping of the Runge- 
Kutte independent variable to the GCS time interval is shown below. This mapping 
should be used, as it will ensure that derivatives can be calculated as required. 

Runge-Kutte 


Subscript 

Number 


1 


h 

1 

> 

1 




x 0 + h/2 

V 




GCS 



1 

-DELTA T— 

>< 

1 

-DELTA T > 

1 


t 2 


C 

to 

Time 

2 



1 

0 Elistory 

n-2 


n-1 

n 

Frame 


A-lll 



where: 

h = 2 x DELTA T 


t = present time 

t = t - DELTA T 
1 o - 


(time for the current frame) 

(time one frame ago) 
t 2 = t 0 - (2 x DELTA T) (time two frames ago) 


The Algorithm 

The following is intended to be a conceptual representation of the Runge-Kutte 
algorithm as applied to GCS. It is not intended to be pseudo code or actual code. In this 
discussion, the subscripts for arrays have been omitted except for the history subscript 
which appears as "(j)" where j is 0, 1, or 2. This has been done here in order to present the 
concepts involved concisely, but without low-level details. The previously calculated 
values of the dependent variables at t l5 although available, are not to be used. Also note 
that the history values of the dependent and sensor variables with subscripts of 3 and 4 
are not used in this adaptation of Runge-Kutte to GCS. 

Notation 

Let kj, k 2 , k k 4 each represent a 3 x 3 array to hold estimate for change in attitude. 

Let 1 , 1 1 , l 4 each represent a vector of size 3 to hold estimate for change in velocity. 

Let m , rry, m, m 4 each represent a scalar to hold estimate for change in altitude. 

Let SENS_ATT(j) represent the GROTATION array with time history subscript j, where j 
is 0, 1, or 2. 

Let SENS_VEL(j) represent the G ROTATION, A ACCELERATION, K MATRIX, and 
TDLR VELOCITY arrays with time history subscript (j), where j = 0, 1, or 2. 

Let SENS_ALT(j) represent the K ALT and AR ALTITUDE arrays with time history 
subscript j, where 
j = 0, 1, or 2. 

Let f att represent the function for derivative of attitude with respect to time. 

Let f vel represent the function for derivative of velocity with respect to time. 

Let f ait represent the function for derivative of altitude with respect to time. 


Algorithm 

Do first estimates of changes using derivatives calculated at t 2 
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k = h x fatt (GP_ATTITUDE(2), SENS_ATT(2)) 

1 =hx fvel (GP_ATTITUDE(2), GP_VEL0CITY(2), SENS_VEL(2)) 
m = h x f ait (GP_ATTITUDE(2), GP_VEL0CITY(2), GP_ALTITUDE(2), 
SENS_ALT(2)) 

Do second estimates of changes using derivatives calculated at t j : 
k =hx f att (GP_ATT1TUDE(2) + k/2, SENS_ATT(1)) 

1 = h x f vel (GP_ATTITUDE(2) + k/2, GP_VELOCITY(2) + 1/2, SENS VEL(l)) 
m = h x f ait (GP_ATT1TUDE(2) + k/2, GP_VEL0C1TY(2) + 1/2, 

GP_ALTITUDE(2) + m/2, SENS ALT(l)) 

Do third estimates of changes using derivatives calculated at t j : 
k = h x fatt (GP_ATTITUDE(2) + k/2, SENS_ATT(1)) 

1 =hx f vel (GP_ATTITUDE(2) + k/2, GP_VELOCITY(2) + 1/2, SENS VEL(l)) 
m 3 = h x fait (GP_ATT1TUDE(2) + k/2, GP_VEL0C1TY(2) + 1/2, 
GP_ALT1TUDE(2) + m/2, SENS ALT(l)) 

Do fourth estimates of changes using derivatives calculated at t # : 
k 4 = h x f att (GP_ATT1TUDE(2) + k , SENS ATT(O)) 

1 = h x f vel (GP_ATTITUDE(2) + k , GP_VEL0C1TY(2) + 1 3 , SENSVEL(O)) 
m 4 = h x fait (GP_ATTITUDE(2) + k, GP_VEL0C1TY(2) + 1 3 , GP_ALT1TUDE(2) + 
m 3 , SENS_ALT(0)) 

Add weighted average of four change estimates to previous value of dependent variable to 
get current dependent variable: 

GP ATTITUDE(O) = GP_ATT1TUDE(2) + 1/6 x (k +2x (k + k 3 ) + k/ 

GP VELOC1TY (0) = GP_VEL0C1TY(2) + 1/6 x (1 + 2 x (1 + 1 ) + 1 ) 

GP ALTITUDE(O) = GP_ALTITUDE(2) + 1/6 x (m + 2 x (m + m^) + m ) 

A.10 COMMUNICATIONS PACKET INSTRUCTIONS 
STRUCTURE OF PACKET 

The global variable PACKET is defined in the data dictionary as an array of 256 elements of type 
lnteger*2. The actual memory which holds this array can also be thought of as an array of 5 12 
elements of type Byte. The message to be transmitted can therefore be thought of as a series of 
contiguous bytes, as illustrated in Table A.5.7. The message on which the checksum is to be 
calculated consists of the synchronization pattern, the sequence number, the sample mask, and the 
data section. The data section always begins in the eighth byte, but the position of the last byte of 
the data section depends upon the particular subframe in which the packet is being transmitted. 
The checksum is always in the two bytes immediately following the last used byte of the data 
section for the subframe, or in other words, immediately following the message. The bytes of 
PACKET following the checksum are unused. 
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Subframe 

Byte Position of 
Message 

Position of Least 
Significant Byte of 
Checksum 

Position of Most 
Significant Byte of 
Checksum 

1 

1 - 129 

130 

131 

2 

1 - 173 

174 

175 

3 

1 -45 

46 

47 


PROCEDURE FOR CALCULATING THE CHECKSUM 

The message polynomial is to be formed as described below, and then is to be multiplied by 2 16 . 
This product polynomial is to be divided by the generator polynomial, using modulo 2 arithmetic. 
The 1 6-bit remainder obtained from this division (with its bits in reverse order) is the checksum, 
and is to be placed into the packet immediately following the message. 

Conventions 

Byte 1 of the synchronization pattern will be referred to as the first byte of the message, while 
the last used byte of the data section will be referred to as the last byte of the message. Each 
number appearing below is given with the most significant digit on the left, and the least 
significant digit on the right. When bit numbers are referenced, they are the VAX FORTRAN 
bit numbers (bit 0 is the least significant bit, while bit 7 is the most significant bit of the byte). 
Form the Message Polynomial 
Let n represent the number of bytes in the message 
Let pbytej represent byte i of the packet 
Let bitj j represent bit j of byte i of the packet. Then, 

<pbytei> = <bitij><biti ; 6><biti j 5><biti j 4><biti ; 3><biti j 2 >< biti j i><biti ; o> 

<mbytei> = <bi ti ,o ><: b i t; i ><b i ti^xbi U ^xb i t; 4 ><b i tj^xbi ti ^xbi t; 7 > 

<Message Polynomial = <mbytei><mbyte 2 > <mbyte n > 

In other words, the message polynomial is formed by taking the bytes of the message in 
order from the first to the last, but within each byte, taking the bits in order from the least to 
the most significant. 

Form the Dividend 

<Dividend> = <Message Polynomial><0000000000000000> 

The dividend is formed by multiplying the message polynomial by 2 16 , or in other words, by 
appending 1 6 zeroes to the end of the polynomial. 

Form the Divisor 

<Divisor> = <1 1000000000000101> 

The divisor is the CRC-16 generator polynomial, which is x 16 + x 15 + x 2 + x° 

Perform the Long Division 

Divide the dividend by the divisor, using modulo two arithmetic. 

Form the Checksum and Place it into the Packet 

Let R represent the final 1 6-bit remainder from the long division. 

Let <Rj> represent bit i of R. Then, 

<R> = 

<R| 5 ><R 1 4 ><R 1 3 ><R 1 2 ><R 1 1 XR10XR9XR8XR7XR6XR5XR4XR3XR2XR1XR0 
> 

<Checksum> = 

<Ro><Rl XR2XR3XR4XR5XR6XR7XR8XR9XR1 0 ><R 1 1 ><R 1 2><R| 3 ><Ri 4><Ri 5 
> 
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Thus, the checksum is the final 1 6-bit remainder, with the bits reversed. 

The checksum is to be placed into the packet in standard VAX byte order, immediately 
following the last used byte of the message. 

CHECKSUM ALGORITHMS 

While different algorithms exist for calculating the checksum, any algorithm used in an 
implementation must be equivalent to, or accomplish the same results as the procedure described 
above. 

EXAMPLE OF THE CALCULATION OF A CHECKSUM 

Assume that the message to be sent consists of four bytes (this message is obviously shorter than 
any message to be sent in any GCS subframe, but it is infeasible to present an example with a 
message of 45 bytes or more). 

Assume the message to be sent is: 


Byte Position 

Contents in 
Hexadecimal 

Contents in 
Binary 

1 

44 

01000100 

2 

4F 

01001111 

3 

56 

01010110 

4 

45 

01000101 
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In this example, the long division(in binary) is as follows: 


11000000000000101 


The remainder is 


I 1 1 1 00 1 01 0001 1001 I 10001 11101 II) 

)oo 1 000 1 0 1 1 1 1 00 1 00 1 1 0 1 0 1 0 1 0 1 000 1 00000000000000000 
11000000000000101 
10010111100101100 
11000000000000101 
10101111001010011 
11000000000000101 
11011110010101100 
11000000000000101 
11110010101001101 
11000000000000101 
11001010100100001 
11000000000000101 
10101001001000001 
11000000000000101 
11010010010001000 
11000000000000101 
10010010001101000 
11000000000000101 
10100100011011010 
11000000000000101 
11001000110111110 
11000000000000101 
10001101110110000 
11000000000000101 
10011011101101010 
11000000000000101 
10110111011011110 
11000000000000101 
11101110110110110 
11000000000000101 
10111011011001100 
11000000000000101 
11110110110010010 
11000000000000101 
1101101100101110 


1101101100101110 
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The checksum is then the remainder with the bits reversed, or: 0111010011011011 

The two bytes of the checksum will then be placed into the bytes immediately following the data 
portion, in standard VAX byte order (low order byte first followed by high order byte) as follows: 


Byte Position 

Contents in 
Hexadecimal 

Contents in 
Binary 

1 

44 

01000100 

2 

4F 

01001111 

3 

56 

01010110 

4 

45 

01000101 

5 

DB 

11011011 

6 

74 

01110100 
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Appendix B: Design Description for the Pluto Implementation of the 
Guidance and Control Software 


Authors: Philip Morris and Rob Angellatta, Lockheed Martin Engineering and Sciences Corp. 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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B.l Introduction to Pluto GCS Design 


This document contains a detailed description of the Pluto software design. The Pluto software 
design fully encompasses all software requirements as presented in the GCS Guidance and 
Control Software Development Specification (ref. B.3) defining a GCS implementation. The 
Pluto design provides full and complete software design specifications suitable for coding a GCS 
implementation. 

B.1.1 Top-Level Description 

A GCS implementation represents the guidance and control subsystem of a planetary landing 
vehicle. The guidance and control subsystem provides navigation, guidance, and attitude control 
for the lander during the terminal phase of a planetary landing. The Terminal phase of a 
planetary landing refers to the vehicle events beginning with the separation from the aeroshell to 
the actual contact with the planet surface. 

The overall objective of the guidance and control subsystem is to effect a safe landing and to 
communicate the lander’s telemetry data to a remote receiving station. Pluto implements a 
velocity-altitude contour (VAC) strategy for fulfilling the guidance and control responsibilities. 
The VAC strategy consists of attempting to match the vehicle’s actual velocity-altitude contour 
with a predetermined descent contour stored in the flight software. 

The communication task consists of preparing the appropriate telemetry data for transmission 
by the on-board communication gear. Preparing the telemetry data involves building a 
communications packet containing various vehicle guidance and control information. 
Periodically, a communications packet is prepared and provided to the communications gear for 
transmission. 

B.1.2 Design Methodology 

The Pluto design specification has been developed using the structured analysis with real time 
extensions (SA/RT) methodology as embodied in Cadre’s Teamwork/SA (ref. B.4) and 
Teamwork/RT software development tools. Cadre’s Teamwork/SA implements the Structured 
Analysis (SA) approach to systems analysis as described by DeMarco (ref. B.5). Cadre’s 
Teamwork/RT is the companion product of Teamwork/SA implementing the real-time extensions 
to SA as described by Hatley (ref. B.6). 

The SA/RT software specification methodology emphasizes data flow between processes. 
Individual processes are activated when their input data is available. In addition, explicit control 
specifications are available for describing process sequencing which is often necessary in real- 
time systems. 

Note that both the SA and SA/RT methodologies are intended to describe software 
development specifications. The Structured Design (SD) methodology, as described by Page- 
Jones (ref. B.7), is more appropriate for describing the Pluto design specifications. However, the 
Pluto design was originally developed using SA/RT and during the transition to in-house software 
development, a decision was made to stay with SA/RT. The potential loss in design description 
capability directly attributable to the SA/RT methodology as compared with the SD methodology 
is minimal as compared to the loss of development man-hours it would cost to convert the design 
from SA/RT to SD during the transition phase. 
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B.1.3 Design Syntax Specifications 

The main criterion for choosing an algorithm language for describing the Pluto design was that 
the algorithms should be clear, concise, and easy to read. No specific language was chosen to 
describe the algorithms of the Pluto design; rather, a “structured English” approach is followed. 
The language, with a few exceptions, is very similar to the Pascal programming language. 

The algorithm description language’s major deviations from Pascal are as follows: First, 
blocks are not delimited by “BEGIN/END” pairs. Blocks are readily apparent and an “END” 
appears in a few instances to clarify the end of a block. Semicolons are not used to signify the 
end of a statement. Again, the end of the statements is quite obvious. 

A few conventions were borrowed from the C programming language. Hexadecimal value 
notation appears as Oxdddd where “Ox” identifies “dddd” as a hexadecimal value. A few bitwise 
binary operators are introduced; “&” signifies bitwise and operation, “XOR” signifies bitwise 
exclusive or operation, and “»” represents the bitwise shift right operation. 

Two syntax features are peculiar to P-Spec 1.8 CP. The at sign “@” was selected to serve as 
an indirection operator. It has the same semantics as Pascal’s “ A ”. The reason for not 
maintaining the caret “ A ” for specifying indirection is that it was previously chosen to signify 
exponentiation. The Modula-2 record syntax was selected for specifying records primarily for 
it’s ability to support deviate record structure. Also, when specifying the records, it is necessary 
to define the size of particular data types. Several terms were introduced for specifying the size 
of particular data elements: byte - an 8-bit quantity, word - a 16-bit quantity, longword a 32-bit 
quantity, and quadword a 64-bit quantity. 

B.2 Design Structure 

In the Teamwork representation of the Pluto design given in B.4, the SA/RT software 
specification methodology organizes the design as a top-down functional decomposition. As 
such, the Pluto design described in this section follows the top-down functional decomposition. 

B.2.1 High-level Software Design 

The ultimate goal of the guidance and control subsystem is to safely land the vehicle onto the 
planet’s surface. Pluto attempts to safely land the vehicle by sensing the vehicle’s position 
relative to the designated landing surface and commanding the vehicle’s locomotive resources in 
an effort to maintain a predetermined descent contour. A secondary goal of the guidance and 
control subsystem is to provide periodic communications of the vehicle’s telemetry data. 

The design context diagram depicts Pluto as a process transforming raw sensor data into 
various output data. The raw sensor data originates from the on-board sensors. As a process, 
Pluto transforms the incoming raw sensor data into engine data which is passed on to the engine 
controller and packet data which is passed on to the communications gear, and when appropriate 
issues the chute released signal. 

Pluto organizes the vehicle terminal descent as a sequence of time slices. That is, Pluto 
divides the vehicle’s journey into regular intervals of time. Each “time slice”, or frame, has a 
well defined time duration as specified by the constant DELTA T. During each frame, Pluto first 
determines the vehicle’s position relative to the planet’s surface and computes the vehicle’s actual 
descent contour, then Pluto decides how closely the actual descent contour matches the 
predetermined VAC, and finally computes and issues the necessary corrective action. 
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As depicted in DFD 0, Pluto processing is partitioned into three processes. Process 1, the 
Sensor Processing Subframe, is responsible for gathering and transforming, if necessary, the 
current information available from the vehicle’s sensors. Process 2, the Guidance Processing 
Subframe, is responsible for determining if the vehicle’s actual VAC matches the preprogrammed 
VAC. Process 3, the Control Law Subframe is responsible for maneuvering necessary to put the 
vehicle closer to the preprogrammed VAC. 

Each frame consists of performing the Sensor Processing Subframe processing, followed by 
the Guidance Processing Subframe processing, followed by the Control Law Subframe 
processing. This control structure is represented by PAT 0-s 1 . When Pluto processing is started, 
the data element GP PHASE is initialized to 1. Pluto processing always begins at the beginning 
of a frame and will always terminate at the completion of a frame. Termination occurs at the 
completion of Control Law Processing Subframe processing during the frame in which Guidance 
Processing Subframe processing asserts the signal GPPFIASE to 5. 

The Sensor Processing Subframe is responsible for collecting the information provided by the 
on-board sensors. The vehicle’s sensors include accelerometers, gyroscopes, temperature 
sensors, an altimeter radar, a four-beam Doppler radar, and a touch-down switch. Sensor 
Processing Subframe processing is decomposed into eight distinct tasks as represented by the 
eight processes of DFD 1. The specific responsibilities assigned to each process are detailed in 
section 2.3 below. 

PAT 1 — s 1 contains the control specification for the processes of DFD 1, Sensor Processing 
Subframe. It is not immediately obvious why the data element SUBFRAMECOUNTER was 
selected as the input to PAT 1-sl. Within each of the three “subframe” processes, a specific order 
of process activation is required. This particular ordering is necessary when the activation of 
some process depends upon the completion of another process. 

The PAT is a control specification designed specifically for representing the ordering of 
process activation. The Pat specifies dependencies in the ordering of process activation via the 
conditions of the input signals. Although in PAT 1-sl, signal conditions are not necessary for 
determining the sequencing of process activation's, the Teamwork SA/RT implementation of the 
PAT requires an input signal. So, an input signal, the data element SUBFRAME COUNTER, 
and it’s value have been selected which always evaluates to “true”. This is also the case with 
PAT 2-sl and PAT 3 -si. 

The major responsibilities of the Guidance Processing Subframe are to determine the current 
state of the vehicle and to determine how closely the actual vehicle VAC matches the 
preprogrammed VAC. These tasks are partitioned into three processes as depicted on DFD 2. 
The process named GCS SIM RENDEZVOUS appears on DFD 1, DFD 2 and DFD 3. All three 
“bubbles” represent the same process. At the beginning of each “subframe”, Pluto is required to 
contact the other vehicle subsystems. GCSSIMRENDEZVOUS processing provides the 
interface to the other vehicle subsystems. The requirements for GCSSIMRENDEZVOUS are 
described in section 2.3 below. 

Once Pluto has determined the present vehicle state, it is necessary to command the vehicle’s 
locomotive resources, if available, in an effort to maintain the desired VAC. This responsibility 
is charged to the Control Law Processing Subframe. This processing is responsible for releasing 
the parachute and computing the appropriate engine commands. The process named CP appears 
on DFD 1, DFD 2 and DFD 3. All three “bubbles” represent the same process. At the end of 
each “subframe”, Pluto is required to transmit particular telemetry data to a remote receiving 
station. CP processing is delegated the task of periodic telemetry communications. 
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B.2.2 Data and Control Flow 


Consistent with the Software Development Specification, Pluto organizes its global storage 
into four data stores labeled EXTERNAL, GUIDANCESTATE, SENSOROUTPUT, 
RUNPARAMETERS. The data dictionary describes the organization of each data store and 
describes each of the data elements comprising the data stores. 

The data stores are represented on DFD 1, DFD 2, and DFD 3. Each DFD clearly depicts the 
data flows between the represented processes and the data stores. It is important to note that a 
non-labeled data flow indicates that all data elements contained in the data store are available in 
the flow. The data flows originating and terminating in the process GCSSIMRENDEZVOUS 
are not labeled. All data elements stored in each of the data stores is available as input and output 
to the process GCS_SIM_RENDEZVOUS. However, GCS_SIM_RENDEZVOUS does not 
necessarily process as input or update as output all of the elements of each data store. The Pluto 
control flow is described above in section 2. 1 High-level software design. 

B.2.3 Module Description 

Process specifications, better known as P-Specs, reside at the lowest level of decomposition in 
the SA/RT development methodology. P-Specs provide a functional description of the necessary 
processing within a process. A map to the P-Specs found in Pluto is presented below. 

The Sensor Processing Subframe provides the guidance and control subsystem with an 
interface to the vehicle’s on-board sensors. The vehicle’s sensors provide Pluto with information 
pertaining to the lander’s current state within the terminal descent operation. Sensor Processing 
Subframe processing is decomposed into eight distinct tasks as described below. 

The GCS SIM RENDEZVOUS process is responsible for the Pluto communications with 
other vehicle subsystems. GCS SIM RENDEZVOUS has both read and write access to all four 
of the global stores. The actual implementation of the GCS SIM RENDEZVOUS functionality 
will be provided to the implementer. GCS SIM RENDEZVOUS is represented in the Sensor 
Processing subframe by DFD 1.1, in the Guidance Processing subframe by DFD 2.1, and in the 
Control Law Processing subframe by DFD 3.1. The functional processing of 
GC S SIM RENDEZV OUS is represented in P-Spec 1.1. 

The ARSP process is responsible for determining the distance from the vehicle to the landing 
surface. ARSP processes data originating from the on-board altimeter radar sensor and reports 
the vehicle’s altitude above the planet’s surface. DFD 1.2 represents the role of ARSP in the 
Sensor processing subframe and P-Spec 1.2 specifies the ARSP functional processing. 

ARSP processing requires an extrapolation algorithm for computing the value of 
ARALTITUDE. The development specifications calls for extrapolating a value for 

ARALTITUDE from a third-order polynomial fitted to the previous four values of 

AR ALTITUDE. Given four equally spaced values, we can approximate the third order function 
representing the polynomial containing the given values. The fifth value in the series may then 
be extrapolated from this function. The value of DELTA T represents the spacing of the values 
stored in AR ALTITUDE. 

ARSP employs the divided difference technique for performing the necessary extrapolation. 
Begin by constructing a difference table for the given values. The first column represents the 
given values of AR ALTITUDE reported in the most recent previous four frames. The second 
column entries are computed as the difference between adjacent column one entries. Similarly, 
the third column entries are computed as the difference between adjacent column two entries. 
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The fourth column is computed as the difference between the column three entries. Letting “A” 
represent the data element “ARAFTITUDE” and “t” represent the current frame, the table 
appears as: 

Frame 

number Column 


1 2 


3 


4 


t-4 A [4 ] 

A [ 3] -A [4 ] 

t-3 A [3 ] (A [2 ] - A [ 3] ) - (A [3 ] - A [4 ] ) 

A [ 2 ] -A [3 ] ( (A [ 1 ] -A [2 ] ) - (A [2 ] -A [ 3] ) ) - ( (A [2 ] -A [3] ) - (A [3 ] -A ['4 ] ) ) 

t-2 A [2 ] (A [ 1] -A [ 2 ] ) - (A [2 ] -A [ 3] j 

A [ 1 ] -A [ 2 ] 

t-1 A [ 1 ] 

t-0 


An extrapolation of the altitude for the current frame is constructed by summing the last 
element of each column: 

A [ 0 ] = A[l] + A[l]-A[2] + ( A [ 1 ] - A [ 2 ] ) - ( A [ 2 ] - A [ 3 ] ) + 

( (A[i]-A[2] )- (A[2]-A[3] ) )-( (A[2]-A[3] )- (A[3]-A[4] ) ) 

Simplifying the equation yields: 

A [ 0 ] = 4 *A [ 1 ] - 6*A [2 ] + 4 *A [ 3 ] - A[4] 

The ASP process is responsible for determining the vehicle accelerations along each of it’s 
three axes. ASP processes data originating from the on-board accelerometers and reports the 
vehicle accelerations. DFD 1.3 represents the role of ASP in the Sensor processing subframe and 
P-Spec 1.3 specifies the ASP functional processing. 

The CP process is responsible for preparing a data packet suitable for transmission by the on- 
board communications gear. CP collects the appropriate data from the four global stores and 
arranges them into a data packet. CP is represented in the Sensor Processing subframe by DFD 
1.8, in the Guidance Processing subframe by DFD 2.3, and in the Control Faw Processing 
subframe by DFD 3.5. The functional processing of CP is described in P-Spec 1.8. 

The GSP process is responsible for determining the vehicle’s rotation rates. GSP processes 
data originating from the on-board gyroscope sensors and reports the vehicle rotation rates. DFD 
1.4 represents the role of GSP in the Sensor processing subframe and P-Spec 1.4 specifies the 
GSP functional processing. 

The TDFRSP process is responsible for computing vehicle’s descent velocities. TDFRSP 
processes data originating from the on-board touch down landing radar sensor and reports the 
vehicle descent velocities. DFD 1.5 represents the role of TDFRSP in the Sensor processing 
subframe and P-Spec 1.5 specifies the TDFRSP functional processing. 

The TDSP process is responsible for determining the vehicle’s touch down status. TDSP 
processes data originating from the on-board touch down sensor and reports the vehicle’s touch 
down status. DFD 1.6 represents the role of TDSP in the Sensor processing subframe and P-Spec 
1.6 specifies the TDSP functional processing. 

The TSP process is responsible for determining the ambient atmospheric temperature. TSP 
processes data originating from the two on-board temperature sensors and reports the ambient 
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atmospheric temperature. DFD 1.7 represents the role of TSP in the Sensor processing subframe 
and P-Spec 1.7 specifies the TSP functional processing. 

TSP contains four algorithms for computing the atmospheric temperature. The algorithm for 
computing the temperature based on the solid state (SS) sensor has been derived as follows. The 
task is to determine the linear function specifying the linear equation containing the points (Ml, 
Tl) and (M2, T2). 

y - mx + b 

where: m is the slope of the line 
b is the y intercept 

substituting the given point (Ml, Tl) for (x, y): 

Tl = m ■ Ml + b 
b = Tl-m-Ml 

the slope of the line is expressed by the delta y divided by delta x: 

T2-TI 

m = 

M2 -Ml 


substituting into the point-slope equation gives: 

T2-TI T2-TI 

solid _state_ temp = T 77 — ~ ■ SS TEMP + T 1 - TTT — ~ ■ Ml 


M2- Ml 


M2 -Ml 


The algorithm for converting a sensor measure residing in the lower parabolic region of the 
thermo-couple (TC) sensor was developed as follows. The first task is to determine the function 
which describes the lower parabolic region of the TC sensor: 

y = ~T fx-hf + k 
4 p 

where: (h,k) is the vertex 

y = (k- p) is the directrix 

Given that "the temperature goes down as the square of the measurement": 


1 2 
y = — -{x-h ) +k 
4 p 

y = -(* - h)~ +k 

— = -1 
4 p 

1 

P= -~4 


standard equation of parabola 
from spec, "goes down as the square" 


The derivative of a function at a given point is equivalent to the slope of the line tangent to the 
function at the given point. 

fix) = y =-(x-h) 2 + k 
f(x)= -2 (x-h) 


The slope of the line tangent to point (M3, T3): 

m = -2(M3- /?) 
m 

h =M3+ — 

2 

Note, the slope of the line tangent to the point is equivalent to the slope of the line containing 
the points (M3, T3) and (M4, T4), so: 
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T4-T3 

M4-M3 


substituting the given point (M3, T3) for (x, y): 


T3 = -(M3-(M3+^)) 2 
k = T3 ' m ' 


+ k 


The function representing the TC sensor lower parabolic region: 


1 2 
y = --(x-h)+k 
4 p 

I m ( m) 2 , T4-T3 

where: p= , h=M 3 + — , k = T3 + — , and m= 

4 2 \2J M4-M3 

f T4-T3 2 


lower _ parabolic _ function = - 


x - 


M 3 + 


M4-M3 

2 


V v 


JJ) 


/ J4-T3 


+ T3 + 


M4-M3 

2 


Similarly, the algorithm for converting a sensor measure residing in the upper parabolic region 
of the thermo-couple sensor was developed as follows. The function which describes the upper 
parabolic region of the TC sensor: 


y = 7 “ • (x - h) 2 + k 
4 p 

where: (h,k) is the vertex 

y = (k- p) is the directrix 


Given "the temp, goes up as the square of the measurement": 

1 2 

y= — • (x - h) +k standard equation of parabola 

4 p 

2 

y=(x- h) + k from spec, "goes up as the square" 

— = 1 
4 p 

1 


The derivative of a function at a given point is equivalent to the slope of the line tangent to the 
function at the given point. 

fix) =y =(x-hf +k 
f (x) = 2(x-h) 


The slope of the line tangent to point (M4, T4): 
m = 2{M4 - h ) 


Note, the slope of the line tangent to the point is equivalent to the slope of the line containing 
the points (M3, T3) and (M4, T4), so: 

T4-T3 

m = 

M4-M3 
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substituting the given point (M4, T4) for (x, y): 


T4 = (M4-(M4+^)f 
k = T4- 1|) 2 


+ k 


The function representing the TC sensor upper parabolic region: 


y = —-(x-h) +k 
4 p 

1 , m , _ ( m ) 2 , T4-T3 

where: p = ~ , h= M4 — — , k= T4 — \ — , and m 

^ 4 2 V2 ) M4-M3 

f T4-T3 


upper _ parabolic function = 


M4 - 


M4-M3 

2 


V v 




/ J4-T3 


+ T4- 


M4-M3 

2 


And finally, the algorithm for converting a sensor measure residing in the linear region of the 
thermo-couple sensor was developed as follows. The task is to determine the linear function 
specifying the linear equation containing the points (M3, T3) and (M4, T4). 


y = mx + b 

where: m is the slope of the line 
b is the y intercept 

substituting the given point (M3, T3) for (x, y): 


T 3 = m ■ M 3 + b 
b = T3- m -M3 

the slope of the line is expressed by the delta y divided by delta x: 


T4-T3 

M4-M3 


substituting into the point-slope equation gives: 

T4 -T3 T4- T3 

tc linear temp = • THERMO TEMP + T3 • M3 

M4 -M3 ~ M4 - M3 


The GP process is responsible for the guidance tasks of the vehicle. Guidance tasks include 
determining the current vehicle VAC, determining how closely the actual vehicle VAC matches 
the preprogrammed VAC, determining which set of engine control law should be in effect, and 
determining the appropriate state for the engines. GP processes data originating in the Sensor 
Processing Subframe, the preprogrammed run parameters, and the engine state data in performing 
the various guidance tasks. DFD 2.2 represents the role of GP in the Sensor processing subframe 
and P-Spec 2.2 specifies the GP functional processing. 

When computing the optimal velocity during the GP processing, there is one case where 
interpolation is necessary and two cases where extrapolation is required. Note, in order to 
implement the following routines, it is assumed that the velocity altitude array data contains at 
least two valid entries. 

Given the point (xq, f(xQ)), the point (xj, f(x] )), and the x value of the desired point (x, f(x)) 
where xq < x < xj, interpolate to find f(x) 
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/(.y)-/(.Yq) = /(.Yi)-/(.Yq) 

X - X 0 Xi - x 0 

f{x) = fi Xq) + ' /(A|) ' /<A|I> (x- X 0 ) 

X 1~X 0 

There are two cases for extrapolation. First, if the desired value is greater than the largest 
value stored in the velocity-altitude contour table, then a value must be extrapolated above the 
largest value stored in the table. Letting (xq, f'( x q ) ) refer to the second largest value stored in the 
velocity-altitude contour table and (xj, f(xj)) refer to the largest value stored in the velocity- 
altitude contour table, the formula for extrapolation is: 

/(.y)-/(.y 0 ) = /(.Yi)-/(.Yq) 

X — Xq Xi - Xq 

fix) = fi Xq) + - /(A '_ ) _- /(A " > •(*- *o) 
x \ x 0 

This is not misprinted, it is indeed the same formula displayed above describing the 
interpolation. 

In the case where the desired value is less than the smallest value stored in the velocity- 
altitude contour table, then a value must be extrapolated below the smallest value stored in the 
table. Letting (xq, f(xQ)) refer to the smallest value stored in the velocity-altitude contour table 
and (x|, f(x ] )) refer to the second smallest value stored in the velocity-altitude contour table, the 
formula for extrapolation is: 

/(-Yq)-/(.y) = /(.Yi)-/(.Yq) 

Xq -X X\ ~Xq 

s, x /v s f( x i)-f( x o) r x 
fix) = fi Xq ) — • (.Y 0 - x) 

x l x 0 

GP is responsible for computing the current values of the data elements GP ATT1TUDE, 
GP_ VELOCITY, and GP ALT1TUDE. The current value of GP ATT1TUDE is expressed by 
the following formula: 
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GP_ ATTITUDE t = GP_ ATTITUDE ,_ 2 + j' ( GP_ ATTITUDE )it 
where 

GP_ ATTITUDE = GP_ ROTATION x GP_ ATTITUDE 


The current value of GP_VELOCITY is expressed by the following formula: 

GP_ VELOCITY t = GP_ VELOCITY ,_ 2 + J' (CP_ VELOCITY )dt 
where 

GP_ VELOCITY = GP_ ROTATION x GP_ VELOCITY + ACCEL + 

(K_ MATRIX x (TDLR_ VELOCITY ■ GP VELOCITY )) 
where ACCEL is a 3x1 matrix specified as: 
do i = l to 3 

ACCEUi] = GRAVTIY ■ GP_ ATTlTUDE[i,3 ] + ACCELERATION^) 

end do 

The current value of GP_ALTITUDE is expressed by the following formula: 

GP_ ALTITUDE, = C,P_ ALTITUDE ,_ 2 + J' [GP_ ALTlTUDE)dt 
where 

GP_ ALTITUDE = (-GP ATTITUDE(\,3}- GP_ VELOCITY [l] + 

- GP~_ ATTnVDE[2,3] • GP VELOCITY (2] + 

■ GP A1TTTUDE[3.3J ■ GP VELOCITY (3J) + 

K ALT ■ (AR ALTITUDE -GP_ ALTITUDE) 


Notice that the formula for computing the rate of change of GPALTITUDE contains 
references to both GP ATT1TUDE and GP VELOC1TY. Because of these references the 
solution for computing the current values of these data elements must solve these three equations 
simultaneously — a system of equations. 

The solution to computing this system of equations proposed in Pluto is based on the fourth- 
order Runge-Kutta (RK) method. Operating on a single equation, the RK method computes four 
estimates for the incremental value and then uses a weighted average of the four estimates to 
compute the result. The solution employs the RK method to the three equations simultaneously 
by computing the first estimate for each equation first, then computing the second estimate for 
each equation second, and so on, finally performing the weighted averages. In this manner, the 
intermediately computed estimates are available to the "downstream" computations of other 
further estimates as necessary. 

The typical application of the RK method involves computing the new value of a function 
given the current value of the function and a step size. The first estimate, kj, of the incremental 

value is determined by multiplying the rate-of-change of the function at the current value by the 
step size. The second estimate, k 2 , of the incremental value is determined by multiplying the 

rate-of-change of the function at the midpoint of the line connecting the known value and the 
estimated new value determined by kj. The straight forward application of the RK method to 

GCS is to treat the value for the current frame as the "new value," the value at the previous frame 
as the "old value," and the step size as DELTA T. 

But, there is a problem implementing this straight forward approach. In order to determine the 
rate-of-change, that is the first derivative of the function, for a specific instance in time, it is 
necessary to know specific sensor measurements at that point in time. The equations for rate-of- 
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change presented above depict the necessary sensor measurements. So, if DELTAT is chosen 
as the step-size, it is not possible to compute the rate-of-change at the "midpoint" of the line 
connecting GP_ VELOC ITY t _ ] and the first estimate of GP VELOCTTY £ 

Likewise in the case of the computation of GPALTITUDE. In order for the necessary sensor 
information to be available for computations involving the "midpoint," the "midpoint" must 
coincide with the execution of the sensor processing subframe. Thus, if a step-size of 2 * 
DELTA T is chosen, the "midpoint" falls on a frame boundary, and the necessary sensor 
information is available. The Pluto design implements the RK method with 2 * DELTA T as the 
step-size, the data element value computed two frames previously as the "old value," and the data 
element current value as the "new value." 

P-Spec 2.2 GP, presented in B.4, contains a detailed description of the application of the 
modified RK method for computing the current values of GP ATT1TUDE, GP VELOCITY, and 
GPALTITUDE. 

The Control Law Processing Subframe provides the guidance and control subsystem with an 
interface to the vehicle’s locomotive resources, namely the axial engines, the roll engines and the 
parachute. The vehicle’s locomotive resources provide Pluto with the means of maneuvering the 
lander. Control Law Processing Subframe processing is decomposed into several distinct tasks. 

The AECLP process is responsible for generating the appropriate axial engine commands. 
AECLP processes data originating from the Sensor Processing Subframe and Guidance 
Processing Subframe processing and computes the axial engine commands. DLD 3.2 represents 
the role of AECLP in the Control Law Processing Subframe and P-Spec 3.2 specifies the AECLP 
functional processing. 

The development specifications present the following formula as a solution for determining a 
value for the data element TE LIMIT, note that the following data elements are abbreviated 
GRAVITY as GRAV, GP_ATTITUDE( 1,3,0) as ATT, VELOCITYERROR as VEL ERROR , 
and OMEGA as D.: 
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— (TE_ LIMIT ) + QTE_ LIMIT 

M - 

GA 

- GAX • (£ + GRAV ■ ATT ) + GVE ■ VEL_ ERROR + GVEI- TE_ INTEGRAL 
rewriting the equation yields: 

~(TE_ LIMIT) + QTE_ LIMIT = 
dt 

GA • ( -GAX • (% v + GRAV ■ ATT) + GVE ■ VEL_ ERROR + GVEI ■ TE_ 1NTEGAL) 
Letting Q = 

GA ■ {-GAX • (j£ v + GRAV ■ ATT ) + GVE ■ VEL_ ERROR + GVEI ■ TE_ INTEGAL) 
gives: 


-^(r£_ LIMIT) + tl-TE_ LIMIT = Q 

which happens to be a first order linear equation. Multiplying each term by the integrating factor 

[a* j fa* fa* 

e J .—{TE LIMIT) + LI TE LIMIT = e J Q 

dt 

simplify: 


d_ 

dt 


TE_ LIMIT e J 



Q 




J 


integrating both terms: 
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r 

( r \ 

1 Cldt . 

a it 

TE_ LIMIT c J =1 

Qc J 

<, > 


- 1 (id: . I Cldt 

TE_ LIMIT = e 3 Q \e J dt 

| Oil 

J 

c — ( 

fer u = Q/ and du = Qdi 
TE_ LIMIT = e _n/ j2 J e^d/ 

-H‘" +c 

= l.e n ' + C 
£1 

TE_LIMIT = Q + CQe~ a ‘ 

Solving for C based on the following initial conditions: 

/=/, = 0 

TE _LIMIT = TE_LIM1T 0 where TE_LIMIT # Is the previously computed TE_ LIMIT 

_ (te_uwt,-£) 

Q 

The final result is: 

7£_ LIMIT = ^ + [ TE - UMIT 0 - ^ j • e~ a 
where Q = 

GA ■ {-GAX • (x v + GRAV • /17T) + GVE • VEL_ ERROR + GVEI- TE_ INTEGRAL} 


The CRCP process is responsible for determining whether or not to release the parachute. 
CRCP determines to release the parachute based on the current state of the parachute and the 
axial engine temperature. DFD 3.3 represents the role of CRCP in the Control Law Processing 
Subframe and P-Spec 3.2 specifies the CRCP functional processing. 

The RECLP process is responsible for generating the appropriate roll engine commands. 
RECLP processes data originating from the Sensor Processing Subframe and Guidance 
Processing Subframe processing and computes the roll engine commands. DFD 3.4 represents 
the role of RECLP in the Control Law Processing Subframe and P-Spec 3.4 specifies the RECLP 
functional processing. 
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B.2.4 Process scheduling 


The Pluto software design specification contains no explicit process scheduling needs. 

B.2.5 Data Dictionary 


The data dictionary contains formal definitions of all the data items presented in the data-flow 
and control-flow diagrams. Teamwork provides an integrated data dictionary for use with the 
SA/RT software development tools. A copy of Pluto’s data dictionary as stored in Teamwork 
may be found in B.4. 

B.2.6 Derived Requirements 

According to DO-178B (ref. B.l) derived requirements are those requirements which are not 
directly traceable to higher level requirements. The GCS Software Development Specification 
goes to great length in presenting the software specifications for a GCS implementation. As such, 
it has not been necessary for the Pluto software design specification to create any derived 
requirements. 
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B.4 Teamwork Design 
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NAME: 

1.1 ;5 

TITLE: 

GCS_SIM_RENDEZVOUS 

INPUT/OUTPUT: 

RAW_SENSOR_DATA: datajn 
GUIDANCE_STATE : datajn 
RUN_PARAMETERS : datajn 
EXTERNAL : datajn 
SENSOR_OUTPUT : datajn 
SENSOR_OUTPUT : data_out 
GUIDANCE_STATE : data_out 
RUN_PARAMETERS : data_out 
PACKET: data_out 
EXTERNAL : data_out 

BODY: 

BEGIN P-Spec 

GCS_SIM_RENDEZVOUS provides the interface to the vehicle. This module is provided by 
the systems group. 

Bubbles 1.1, 2.1, 3.1 and the associated P- Specs represent a single process. 

END P-Spec 
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NAME: 

1.2;31 

TITLE: 

ARSP 

INPUT/OUTPUT: 
AR_ALTITUDE : datajn 

AR_COUNTER : datajn 

AR_FREQUENCY : datajn 

AR_STATUS : datajn 

K_ALT : datajn 

AR_ALTITUDE : data_out 

AR_STATUS : data_out 

K ALT : data out 


BODY: 

BEGIN P_SPEC 

(************************************************************************* 

* ARSP -- Altimeter Radar Sensor Processing 

* 

* ARSP processing is responsible for: 

* 1) maintaining the history of the altitude and altimeter sensor data 

* elements, 

* 2) determining the operational status of the altimeter radar sensor, and 

* 3) Reporting the current altitude. 

*************************************************************************J 


( ********************************************************************'***** 

* 1) Maintain the history of the altitude and the sensor status by 

* "rotating variables.” Each of the three data elements AR_ALTITUDE, 

* AR_STATUS , and K_ALT are defined as five element arrays. The first 

* element of each array, element zero, holds the most recently computed 

* value. The last element of each array, element four, holds the 

* oldest maintained value. In shifting the values stored in these 

* data elements, a multi- frame history is maintained. 

*************************************************************************J 

AR_ALTITUDE[4] := AR_ALTITUDE [ 3 ] 

AR_ALTITUDE[3] := AR_ALTITUDE[2] 

AR_ALTITUDE[2] := AR_ALTITUDE[1] 

AR_ALTITUDE[1] := AR_ALTITUDE[0] 

AR_STATUS [4] := AR_STATUS[3] 

AR_STATUS [3] := AR_STATUS[2] 

AR_STATUS [ 2 ] := AR_STATUS[1] 

AR_STATUS [1] := AR_STATUS[0] 


Cadre Technologies, Inc. 
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K_ALT [ 4 ] := K_ALT [ 3 ] 
K_ALT [ 3 ] := K_ALT [ 2 ] 
K_ALT [ 2 ] := K_ALT [ 1 ] 
K_ALT [ 1 ] := K_ALT [ 0 ] 


* 2) The data element AR_STATUS represents the operational status 

* of the altimeter radar sensor. If an echo has been received, 

* then the sensor status is deemed "healthy" (value 0). If an 

* echo has not been received, the sensor status is reported as 

* "failed" (value 1). The GP process references the data element 

* K_ALT to determine which method was used to determine the 

* current altitude. If either method A or B, as described below, is 

* employed to compute the current altitude, the value for K_ALT is 

* reported as "1." If method C is used to compute the altitude, 

* the value for K_ALT is reported as "0." 

* 

* 3) There are three methods for determining the altitude. 

* 

* A) If an echo has been received, then the altitude will be computed 

* from the sensor measurement. 

* 

* B) If an echo has not been received, and all four of the maintained 

* altitude sensor history statuses are "heathly, " then the value 

* for the current altitude is estimated by fitting a third-order 

* polynomial to the altitude history data values (see description 

* below) . 

* 

* C) If an echo has not been received, and at least one of the 

* maintained altitude sensor history statuses is "failed," then 

* the value for the the current altitude is estimated by reporting 

* the mostly recently reported value for the altitude. 

* a*********************************************************************** J 


^************************************************************************* 

* If an echo has been recieved, then the lower order fifteen bits of 

* AR_COUNTER contain the raw sensor measurement, and the upper bit of 

* AR_COUNTER will be clear (ie: 0). When an echo has not been received, 

* the AR_COUNTER will contain 16 set bits (ie: OxFFFF) . 

* 

* It is known that this design will be implemented on VAX/VMS in FORTRAN. 

* The data type of AR_COUNTER is integer*2 and the valid value range 

* is specified as [-1, 32767]. VAX/VMS uses twos complement method for 

* representing negative values. Thus, when an echo has not been recieved, 

* the AR_COUNTER will contain the value of -1. Similarly, when an echo 

* has been received, AR_COUNTER will contain a non-negative value. 

*************************************************************************J 

if (an echo has been recieved) then {1] 

(*** report the sensor status as healthy ***) 

AR_STATUS [0] := 0 (* healthy *) 

K_ALT [ 0 ] := 1 (* method A *) 

(*** A) compute the altitude from the sensor measurement ***) 
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AR_ALTITUDE := (AR_COUNTER * 3x10 A 8) / (2 * AR_FREQUENCY) 

else (* no echo received *) {1} 

(*** report the sensor status as failed ***) 

AR_STATUS [0] := 1 (* failed *) 

*** if at least one of the history sensor status is "failed” ***) 

if (AR_STATUS [1] = 1 OR AR_STATUS[2] = 1 OR {2] 

AR_STATUS [ 3 ] = 1 OR AR_STATUS[4] = 1) then 

K_ALT [ 0 ] := 0 (* method C *) 

(*** C) return previously computed value ***) 

(*** range check the altitude ****) 

if (AR_ALTITUDE[1] < 0) {3] 

display-error("%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"ARSP ARSP", FRAME_COUNTER , 

"AR_ALTITUDE " , AR_ALTITUDE [ 1 ] ) 

else if (AR_ALTITUDE[1] > 2000) {3} 

display-error( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"ARSP ARSP", FRAME_COUNTER , 

"AR_ALTITUDE" , AR_ALTITUDE[1] ) 

end if {3} 

AR_ALTITUDE [ 0 ] := AR_ALTITUDE[1] (* this should already exist *) 

else (* all sensor status histories are "healthy" *) {2) 

(*** B) extrapolate the altitude ***) 

K_ALT [ 0 ] := 1 (* method B *) 

(*** range check the altitude ****) 

if (AR_ALTITUDE[1] < 0) {3} 

display-error ( ”%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED" , 
"ARSP ARSP", FRAME_COONTER, 

"AR_ALTITUDE" , AR_ALTITDDE) 

else if (AR_ALTITUDE[1] > 2000) {3} 

display - error ( " %EXCEPTIONAL- CONDITION- GCS-DPPER_LIMIT_EXCEEDED" , 


"ARSP ARSP", FRAME_COUNTER , 
"AR_ALTITUDE" , AR_ALTITUDE) 


end if 

(3) 

if ( AR_ALTITUDE [ 2 ] < 0) 

(3) 


display-error ( "^EXCEPTIONAL -CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"ARSP ARSP", FRAME_COUNTER , 

"AR_ALTITUDE" , AR_ALTITUDE) 


Cadre Technologies, Inc. 
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else if (AR_ALTITUDE[2] > 2000) {3] 

display -error ( "%EXCEPTIONAL-CONDITION-GCS-OPPER_LIMIT_EXCEEDED" , 
"ARSP ARSP", FRAME_COUNTER , 

"ARJUVTITUDE”, AR_ALTITUDE) 

end if {3} 

if ( AR_ALTITODE [ 3 ] < 0) {3} 

display - error ( " %EXCEPTIONAL -CONDITION- GCS - LOWER_LIMIT_EXCEEDED " , 
"ARSP ARSP", FRAME_COUNTER , 

”AR_ALTITUDE " , AR_ALTITUDE ) 

else if (AR_ALTITUDE[3] > 2000) {3} 

display-error("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"ARSP ARSP", FRAME_COUNTER , 

"AR_ALTITUDE", AR_ALTITUDE) 

end if {3} 

if ( AR_ALTITUDE [ 4 ] < 0) {3} 

display-error ( " %EXCEPTIONAL- CONDITION- GCS -LOWER_LIMIT_EXCEEDED” , 
"ARSP ARSP", FRAME_COUNTER , 

"AR_ALTITUDE" , AR_ALTITUDE) 

else if (AR_ALTITUDE[4] > 2000) {3} 

display-error ( ”%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"ARSP ARSP", FRAME_COUNTER , 

"AR_ALTITDDE" , AR_ALTITUDE) 

end if {3} 

AR_ALTITUDE[0] := 4 * AR_ALTITDDE [ 1 ] - 6*AR_ALTITUDE [ 2 ] + 
4*AR_ALTITUDE [ 3 ] - AR_ALTITUDE[4] 

end if {2} 

end if [1) 

END P_SPEC 
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NAME: 

1.3;36 

TITLE: 

ASP 

INPUT/OUTPUT: 

A_ACCELERATION : datajn 

A_BIAS : datajn 

A_COUNTER : datajn 

A_GAIN_0 : datajn 

A_SCALE : datajn 

A_STATUS : datajn 

ALPHA_MATRIX : datajn 

ATMOSPHERIC_TEMP : datajn 

G1 : datajn 

G2 : datajn 

A_ACCELERATION : data_out 
A_STATUS : data_out 

BODY: 

BEGIN P_SPEC 

(****************^******************************************************* 

* ASP -- Accelerometer Sensor Processing 

* 

* ASP processing is responsible for: 

* 1) maintaining the history of the accelerations and accelerometer 

* sensor statuses, 

* 2) determining the operational status of the accelerometer sensors, and 

* 3) Reporting the current vehicle accelerations along each of the 

* vehicle's three axes. 

************************************************************************* j 

(************************************************************************* 

* 1) Maintain the history of the vehicle accelerations and 

* accelerometer sensor status by "rotating variables." 

* Both of the data elements A_ACCELERATION and A_STATUS are defined as 

* two diminsional arrays. The first dimension of each array represents 

* a vehicle axis: x-axis (1), y-axis (2), z-axis (3). The second 

* diminsion of each data element represents a history. For 

* A_ACCELERATION , the history is five deep and for A_STATUS the history 

* is four deep. The first element of each history, element zero, holds 

* the most recently computed value. The last element of each history, 

* element four or three respectively, holds the oldest maintained value. 
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* In shifting the values stored in these data elements, a multi-frame 

* history is maintained. 

*************************************************************************) 

ACCELERATION [1, 4] := ACCELERATION [1, 3] 

ACCELERATION [1, 3] := ACCELERATION [1, 2] 

ACCELERATION [1, 2] := ACCELERATION [1, 1] 

ACCELERATION [1, 1] := ACCELERATION [1, 0] 

ACCELERATION [2, 4] := ACCELERATION [ 2 , 3] 

ACCELERATION [2, 3] := ACCELERATION [ 2 , 2] 

ACCELERATION [2, 2] := ACCELERATION [ 2 , 1] 

ACCELERATION [2, 1] := ACCELERATION [ 2 , 0] 

ACCELERATIONS, 4] := ACCELERATION [ 3 , 3] 

ACCELERATIONS, 3] := ACCELERATION [ 3 , 2] 

ACCELERATIONS, 2] := ACCELERATION [3, 1] 

ACCELERATIONS, 1] := ACCELERATION [3, 0] 

A_STATUS [1, 3] := A_STATUS[1, 2] 

A_STATUS [1, 2] := A_STATUS[1, 1] 

A_STATUS [1, 1] := A_STATUS[1, 0] 

A_STATUS [ 2 , 3] := A_STATUS[2, 2] 

A_STATUS [2 , 2] := A_STATUS[2, 1] 

A_STATUS [2, 1] := A_STATUS[2, 0] 

A_STATUS [3, 3] := A_STATUS[3, 2] 

A_STATOS [ 3 , 2] := A_STATUS[3, 1] 

A_STATUS [3 , 1] := A_STATUS[3, 0] 

^************************************************************************* 

* 2) and 3), determine the operational status and the vehicle 

* accelerations for each axis. 

************************************************************************* j 

(*** range check the atmospheric temperature ****) 

if (ATMOSPHERIC_TEMP < -200) then {1} 

display-error ( " %EXCEPTIONAL -CONDITION- GCS -LOWER_LIMIT_EXCEEDED" , 

"ASP ASP", FRAME_COUNTER , 

"ATMOSPHERICJTEMP" , ATMOSPHERIC_TEMP) 

else if (ATMOSPHERICJTEMP > 25) then (1} 

display-error ( "%EXCEPTIONAL - CONDITION -GCS -OPPER_LIMIT_EXCEEDED" , 

"ASP ASP", FRAME_COUNTER , 

"ATMOSPHERIC_TEMP" , ATMOSPHERIC_TEMP) 
end if ( 1 ) 

(*** compute the preliminary value for the accelerations ***) 

Let accel_m be a 3x1 matrix 

compute each element (i := 1 to 3) of accel_m as follows: 
accel_m[i] := A_BIAS[i] + a_gain * A_COUNTER [ i ] 
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where 

a_gain := A_GAIN_0[i] + (G1 * ATMOSPHERIC_TEMP) + 

(G2 * ATM0SPHERIC_TEMP A 2 ) 

viewing the "current" elements of A_ACCELERATION as a 3x1 matrix, 


| A_ACCELERATION [ 1 , 0] | 
| A_ACCELERATION [ 2 , 0] | 
| A_ACCELERATION [ 3 , 0] | 


the prelimenary values for A_ACCELERATION are computed from the 
matrix multication: 

A_ACCELERATION := ALPHA.MATRIX X accel_m 

^************************************************************************ 

* Determine whether or not the preliminary values for the 

* accelerations are reasonable. The preliminary value for an 

* acceleration is deemed reasonable: 1) if it differs from the mean 

* of the previous three measurements by not more than A_SCALE 

* standard deviations; 2) when any of the three accelerometer 

* history statuses is "unhealthy" (value 1) . If a preliminary 

* acceleration value is found to be reasonable, 

* then it is reported as the acceleration for it's axis. If a 

* preliminary value is not found to be reasonable, then the 

* mean of the previous three measurements is reported as the 

* acceleration for that axis. 

* 

* The current value for the sensor status is determined directly 

* from the reasonableness of the value of the preliminary 

* accleration. If the preliminary acceleration is reasonable, the 

* sensor status is deemed "healthy " (value 0). If the preliminary 

* acceleration is not reasonable, the sensor status is deemed 

* "unhealthy." 

************************************************************************ j 


do for each axis (i := 1 to 3) 

A_STATUS [ i , 0] := 0; (* set sensor status to "healthy" *) 

if (A_STATUS [i, 1] = 0) AND A_STATUS[i, 2] = 0 AND {1} 

A_STATUS [i, 3] = 0) then 

if ( (A_ACCELERATION[i,l] <> A_ACCELERATION [ i , 2] ) OR 

(A_ACCELERATION[i, 1] <> A_ACCLERATION [ i , 3 ] ) ) then {2] 

(*** compute the mean of the previous three values ***) 

(*** range check the acceleration values ****) 

if (A_ACCELERATION[i, 1] < -20) then (3) 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
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"ASP ASP”, FRAME_COUNTER , 

"A_ACCELERATION" , A_ACCELERATION [ i , 1]) 

else if ( A_ACCELERATION [ i , 1] > 5) then {3} 

display-error("%EXCEPTIONAL-CONDITION-GCS-DPPER_LIMIT_EXCEEDED", 
"ASP ASP", FRAME_COUNTER , 

"A_ACCELERATION", A_ACCELERATION [ i , 1]) 
end if {3} 

if (A_ACCELERATION[i, 2] < -20) then {3} 

display-error ("%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"ASP ASP", FRAME_COUNTER , 

"A_ACCELERATION", A_ACCELERATION [ i , 2]) 

else if ( A_ACCELERAT ION [ i , 2] > 5) then {3} 

display-error ( "%EXCEPTIONAL- CONDITION- GCS-UPPER_LIMIT_EXCEEDED" , 
"ASP ASP”, FRAME_COUNTER , 

"A_ACCELERATION" , A_ACCELERATION [ i , 2]) 
end if {3} 

if ( A_ACCELERATION [ i , 3] < -20) then {3] 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"ASP ASP", FRAME_COUNTER, 

"A_ACCELERATION", A_ACCELERATION[i, 3]) 

else if (A_ACCELERATION[i, 3] > 5) then {3) 

display-error ("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"ASP ASP", FRAME_COUNTER , 

"A_ACCELERATION" , A.ACCELERATION [ i , 3]) 
end if {3} 

mean : = ( (A_ACCELERATION[i, 1] + A_ACCELERATION [ i , 2] + 
A_ACCELERATION[i, 3]) / 3 

(*** compute the standard deviation ***) 

temp := ( (A_ACCELERATION[i, 1] - mean) A 2 + 

(A_ACCELERATION[i, 2] - mean) A 2 + 

( A_ACCELERATION [ i , 3] - mean) A 2) / 3 

sd := SQRT(temp) 


if (ABS(mean - A_ACCELERATION [ i , 0]) > A_SCALE * sd) then [3] 

A_ACCELERATION[i, 0] := mean 

A_STATUS[i, 0] := 1 (* set sensor status to "unhealthy" *) 
end if { 3 } 

end if {2} 

end if { 1 } 

end do (* for each axis *) 

END P_SPECA_STATUS [ i , 0] := 0; (* set sensor status to "healthy" *) 
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NAME: 

1.4;16 

TITLE: 

GSP 

INPUT/OUTPUT: 

ATMOSPHERIC_TEMP : datajn 

G3 : datajn 

G4 : datajn 

G_COUNTER : datajn 

G_GAIN_0 : datajn 

G_OFFSET : datajn 

G_ROTATION : datajn 

G_ROTATION : data_out 

G_STATUS : data_out 

BODY: 

BEGIN P_SPEC 

^************************************************************************* 

* GSP -- Gyroscopy Sensor Processing 

* 

* GSP processing is responsible for: 

* 1) maintaining the history of the vehicle rotation rates, 

* 2) determining the operational status of the gyroscope sensors, and 

* 3) Reporting the current vehicle rotation rates along each of the 

* vehicle's three axes. 

*************************************************************************J 


(★********************★******★ ******************************************** 

* 1) Maintain the history of the vehicle rotation rates by "rotating 

* variables." The data element G_R0TATI0N is defined as a two 

* diminsional array. The first diminsion represents a vehicle axis: 

* x-axis (1), y-axis (2), and z-axis (3). The second diminsion 

* represents a five deep history. The first element of the history (0), 

* holds the most recently computed value. The last element of the 

* history (4), holds the oldest maintained value. In shifting the 

* values stored in these data elements, a multi-frame history is 

* maintained. 

************************************************************************* j 


G_R0TATI0N[1, 4] 
G_R0TATI0N[1, 3] 
G_R0TATI0N[1, 2] 
G_ROTATION[l, 1] 


= G_R0TATI0N[1, 3] 
= G_R0TATI0N[1, 2] 
= G_R0TATI0N [ 1 , 1] 
= G_ROTATION [ 1 , 0] 
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G_R0TATI0N[2, 4] 
G_R0TATI0N[2, 3] 
G_R0TATI0N[2, 2] 
G_R0TATI0N[2, 1] 

G_R0TATI0N[3, 4] 
G_R0TATI0N[3, 3] 
G_R0TATI0N [ 3 , 2] 
G_R0TATI0N [ 3 , 1] 


= G_R0TATI0N[2, 3] 
= G_R0TATI0N[2, 2] 
= G_R0TATI0N[2 ; 1] 
= G_R0TATI0N[2, 0] 

= G_ROTATION [ 3 , 3] 
= G_ROTATION[3, 2] 
= G_R0TATI0N[3, 1] 
= G_ROTATION[3, 0] 


^************************************************************************* 

* 2) determining the operational status of the gyroscope sensors. 

* The operational status of the gyroscope sensors is always reported 

* as "healthy" (value 0). 

*************************************************************************) 
G_STATUS := 0 


* 3) Reporting the current vehicle rotation rates along each of the 

* vehicle's three axes. 

*************************************************************************J 


(*** range check the atmospheric temperature ****) 

if (ATMOSPHERIC_TEMP < -200) then 

display - error ( ” %EXCEPTIONAL- CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"GSP GSP", FRAME_COUNTER , 

"ATMOSPHERICJTEMP" , ATMOSPHERIC_TEMP) 

else if ( ATMOSPHERIC_TEMP > 25) then 

display-error ("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED\ 
"GSP GSP", FRAME_COUNTER , 

"ATMOSPHERICJTEMP” , ATMOSPHERICJTEMP) 

end if 


^************************************************************************* 

* The raw sensor data stored in G_C0UNTER represents the vehicle rate 

* of rotation about a specific axis. The sensor data is 

* stored in a modified sign magnitude format. The lower 14-bits 

* represent the magnitude of the rotation and the most significant 

* bit (bit 15) represents the sign. Bit 14 is not used. A 

* positive value of G_COUNTER indicates a positive rotation about 

* the vehicle axis consistent with a right handed coordinate system, 

* while a negative value indicates a negative rotation consistent 

* with a right handed coordinate system. 
***********★*************************************************************) 


do for each axis (i := 1 to 3) 

(*** convert the raw sensor ... ***) 

{************************************************************************* 

* Convert the raw sensor data from the modified sign magnitude 

* format into an appropriate format for use by the target CPU, in 

* this case two's complement. Positive values are represented in 
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* the same fashion in sign magnitude and two's complement, however, 

* negative sensor values must be massaged. 

* 

* Transfer the magitude of the rotation from G_C0UNTER to the local 

* data element named counter by masking bits 14 and 15 from 

* G_C0UNTER. If G_C0UNTER bit 15 is clear, the data element counter 

* now contains the properly converted value. If G_C0UNTER bit 15 is 

* set, the value of data element counter must be negated. 

^ ************************************************************************* 

* The symbol represents a bitwise AND operation 

* the notation 'Oxdddd' represents a hexidecimal value 

*************************************************************************J 

counter := G_C0UNTER[i] & 0x3FFF 

if ( (G_C0UNTER[i] & 0x8000) = 1) 
counter := 0 - counter 

end if 

(*** compute the vehicle rotation from the sensor data ***) 

G_ROTATION [ i , 0] := G_OFFSET[i] + g_gain * counter 
where 

g_gain := G_GAIN_0[i] + (G3 * ATMOSPHERIC_TEMP) + 

(G4 * ATM0SPHERIC_TEMP A 2) 

end do (* for each axis *) 

END P_SPEC 
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NAME: 

1.5;27 

TITLE: 

TDLRSP 

INPUT/OUTPUT: 

DELTA_T : datajn 

FRAME_BEAM_UNLOCKED : datajn 
FRAME_COUNTER : datajn 
K_MATRIX : datajn 
TDLR_ANGLES : datajn 
TDLR_COUNTER : datajn 
TDLR_GAIN : datajn 
TDLR_LOCK_TIME : datajn 
TDLR_OFFSET : datajn 

TDLR_STATE : datajn 

TDLR_VELOCITY : datajn 
FRAME_BEAM_UNLOCKED : data_out 

K_MATRIX : data_out 
TDLR_STATE : data_out 

TDLR_STATUS : data_out 

TDLR VELOCITY : data out 


BODY: 

BEGIN P_SPEC 

* TDLRSP -- Touch Down Landing Radar Sensor Processing 

* 

* TDLRSP processing is responsible for: 

* 1) Maintaining the history of the vehicle velocities and the 

* velocity computation indicator, 

* 2) Determining the operational status of touch down landing radar 

* sensor, and 

* 3) Reporting the current vehicle velocities along each of the 

* vehicle's three axes, and 

* 4) Reporting the velocity computation indicators. 

* 

★★★★★★*******************************************************************J 


(************************************************************************* 

* 1) Maintain the history of the vehicle velocities and the 

* velocity computation indicator by "rotating variables." The data 

* element TDLR_VELOCITY is defined as a two dimensional array. The 

* first dimension represents a vehicle axis: x-axis (1), y-axis 

* (2), and z-axis (3). The second dimension represents a five deep 

* history. The data element K_MATRIX is defined as a three 

* dimensional array (1..3, 1..3, 0..4). The velocity computation 

* indicators are arranged as a 3x3 matrix, represented by the first 
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* two dimensions of K_MATRIX. The third dimension represents a 

* five deep history. The first element of the history, element 

* zero, holds the most recently computed value. The last element 

* of the history, element four, holds the oldest maintained value. 

* In shifting the values stored in these data elements, a 

* multi- frame history is maintained. 

* ★★★★*★★*★***★***★★***★★★★★★*★**★*****★★*★**★★*★★★*★*******************★'* J 


TDLR_VELOCITY [ 1 , 4] 
TDLR_VELOCITY [ 1 , 3] 
TDLR_VELOCITY [ 1 , 2] 
TDLR_VELOCITY [ 1 , 1] 

TDLR_VELOCITY [ 2 , 4] 
TDLR_VELOCITY [2 , 3] 
TDLR_VELOCITY [ 2 , 2] 
TDLR_VELOCITY [ 2 , 1] 

TDLR_VELOCITY [ 3 , 4] 
TDLR_VELOCITY [ 3 , 3] 
TDLR_VELOCITY [ 3 , 2] 
TDLR_VELOCITY [ 3 , 1] 

K_MATRIX [ 1 , 1, 4] 
K_MATRIX [ 1 , 2, 4] 
K_MATRIX [ 1 , 3, 4] 
K_MATRIX [ 2 , 1, 4] 
K_MATRIX [ 2 , 2, 4] 
K_MATRIX[2, 3, 4] 
K.MATRIX [ 3 , 1, 4] 
K_MATRIX [ 3 , 2, 4] 
K_MATRIX [ 3 , 3, 4] 

K_MATRIX[1, 1, 3] 
K_MATRIX[1, 2, 3] 
K_MATRIX[1, 3, 3] 
K_MATRIX[2, 1, 3] 
K_MATRIX[2, 2, 3] 
K_MATRIX[2, 3, 3] 
K_MATRIX [ 3 , 1, 3] 
K_MATRIX[3, 2, 3] 
K_MATRIX [ 3 , 3, 3] 

K_MATRIX[1, 1, 2] 
K_MATRIX [ 1 , 2, 2] 
K_MATRIX[1, 3, 2] 
K_MATRIX [ 2 , 1, 2] 
K.MATRIX [ 2 , 2, 2] 
K_MATRIX [ 2 , 3, 2] 
K_MATRIX [ 3 , 1, 2] 
K_MATRIX [ 3 , 2, 2] 
K_MATRIX [ 3 , 3, 2] 

K_MATRIX [ 1 , 1, 1] 
K_MATRIX[1, 2, 1] 
K_MATRIX [ 1 , 3, 1] 


= TDLR_VELOCITY [ 1 , 3] 
= TDLR_VELOCITY [ 1 , 2] 
= TDLR_VELOCITY [ 1 , 1] 
= TDLR_VELOCITY [ 1 , 0] 

= TDLR_VELOCITY [ 2 , 3] 
= TDLR_VELOCITY [ 2 , 2] 
= TDLR_VELOCITY [ 2 , 1] 
= TDLR_VELOCITY [ 2 , 0] 

= TDLR_VELOCITY [ 3 , 3] 
= TDLR_VELOCITY [ 3 , 2] 
= TDLR_VELOCITY [ 3 , 1] 
= TDLR_VELOCITY [ 3 , 0] 

= K_MATRIX [ 1 , 1, 3] 

= K_MATRIX [ 1 , 2, 3] 

= K_MATRIX [ 1 , 3, 3] 

= K_MATRIX [ 2 , 1, 3] 

= K_MATRIX [ 2 , 2, 3] 

= K_MATRIX[2, 3, 3] 

= K_MATRIX[3, 1, 3] 

= K_MATRIX [ 3 , 2, 3] 

= K_MATRIX [ 3 , 3, 3] 

= K_MATRIX[1, 1, 2] 

= K_MATRIX[1, 2, 2] 

= K_MATRIX[1, 3, 2] 

= K_MATRIX[2, 1, 2] 

= K_MATRIX[2, 2, 2] 

= K_MATRIX[2, 3, 2] 

= K_MATRIX [ 3 , 1, 2] 

= K_MATRIX [ 3 , 2, 2] 

= K_MATRIX [ 3 , 3, 2] 

= K_MATRIX[1, 1, 1] 

= K_MATRIX[1, 2, 1] 

= K_MATRIX [1, 3, 1] 

= K_MATRIX [ 2 , 1, 1] 

= K_MATRIX [ 2 , 2, 1] 

= K_MATRIX [ 2 , 3, 1] 

= K_MATRIX [ 3 , 1, 1] 

= K_MATRIX [ 3 , 2, 1] 

= K_MATRIX [ 3 , 3, 1] 

= K_MATRIX [ 1 , 1, 0] 

= K_MATRIX [ 1 , 2, 0] 

= K_MATRIX[1, 3, 0] 
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K_MATRIX [ 2 , 1, 1] 
K_MATRIX [ 2 , 2, 1] 
K_MATRIX [ 2 , 3, 1] 
K_MATRIX [ 3 , 1, 1] 
K_MATRIX [ 3 , 2, 1] 
K_MATRIX [ 3 , 3, 1] 


= K_MATRIX[2, 1, 0] 
= K_MATRIX[2, 2, 0] 
= K_MATRIX [ 2 , 3, 0] 
= K_MATRIX [ 3 , 1, 0] 
= K_MATRIX [ 3 , 2, 0] 
= K_MATRIX [ 3 , 3, 0] 


* 2) Determine the operational status of touch down landing radar 

* sensor. 

* 

* The operational status of the TDLR sensor is always reported 

* as "healthy" (value 0). 

************************************************************************* ) 


TDLR_STATUS [1] 

:= 0 

TDLR_STATUS [ 2 ] 

:= 0 

TDLR_STATUS [ 3 ] 

:= 0 

TDLR_STATUS [ 4 ] 

:= 0 


^★************************************************************************ 

* 3) Reporting the current vehicle velocities along each of the 

* vehicle's three axes and reporting the velocity computation 

* indicators . 

*************************************************************************) 

^************************************************************************* 

* 3A) Determine the state of the four radar beams. 

* 

* The data element TDLR_STATE contains the state of the radar 

* beams. 

* 

* Valid radar beam states are "locked” (value 1) and "unlocked" 

* (value 0). The present state of a radar beam is determined from 

* the current value of the sensor data and the previous state of 

* the radar beam. A sensor measurement of zero indicates that the 

* radar beam echo was not received and the radar beam is considered 

* to be "unlocked." A non-zero sensor measurement indicates that a 

* radar beam echo was received, but does not imply a radar beam 

* state of "locked." Because, once a radar beam is declared 

* "unlocked," it is rendered unusable (remains "unlocked" 

* regardless of the sensor data value) for a specified period of 

* time. This waiting period must be implemented in the software. 

* 

* A beam is deemed "locked" when 1) the current sensor value 

* contains a non-zero value and the beam's previous state was 

* "locked"; or 2) the current sensor value contains a non- zero 

* value and the beam's previous state was "unlocked" and the 

* elapsed time since the beam was determined "unlocked" is greater 

* than or equal to the sensor recovery period. 

* 

* The data element TDLR_LOCK_TIME specifies the unlocked sensor 

* recovery (waiting) period. The data element FRAME_BEAM_UNLOCKED 

* is updated with the value of the FRAME_COUNTER during the frame 

* in which a radar beam state is first determined as "unlocked." 

* The data element DELTA_T specifies in seconds the duration of a 
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* single frame. Thus the elapsed time since a radar beam was 

* declared "unlocked" can be determined by subtracting the present 

* value of FRAME_COUNTER from the value of FRAME_BEAM_UNLOCKED and 

* multipling the result by the value of DELTA_T. 

★★***********************************************************************J 


do (for each radar beam i :=(1 to 4)) {1} 

if ( TDLR_COUNTER [ i ] = 0) then (* beam is unlocked *) {2} 

if (TDLR_STATE[i] = 1) then (* beam was locked *) (3} 

TDLR_STATE [ i ] := 0 (* set unlocked *) 

FRAME_BEAM_UNLOCKED[i] := FRAME_COUNTER 

else (* the beam was unlocked *) {3} 

elapsed_time := DELTA_T * ( FRAME_COUNTER - FRAME_BEAM_UNLOCKED [ i ] ) 

if ( elapsed_time >= TDLR_LOCK_TIME ) then {4} 

FRAME_BEAM_UNLOCKED[i] := FRAME_COUNTER 
end if {4} 

end if {3} 

else (* the sensor measurement != 0 *) {2} 

if (TDLR_STATE[i] = 0) then (* beam was unlocked *) {3] 

elapsed_time := DELTA_T * ( FRAME_COUNTER - FRAME_BEAM_UNLOCKED [ i ] ) 

if (elapsed_time >= TDLR_LOCK_TIME) then {4] 

TDLR_STATE[i] := 1 (* set locked *) 

end if {4} 

end if {3} 

end if [2} 

end do (* for each beam i *) {1} 


* 3B) Determine the beam velocities. 


do (for each radar beam i := (1 to 4)) 

b[i] := TDLR_OFFSET + TDLR_GAIN * TDLR_COUNTER [ i ] 
end do (* for each beam *) 


* 3C) Determine the "processed" beam velocities, and 

* 4) Determine the velocity computation indicators. 

(************************************************************************* 

* Compute a "processed" beam velocity for each of the three axes as 

* specified by the following table: 


Cadre Technologies, Inc. 


B-43 




1 1 :30:49 1 0 Jul 95 GCS_pluto_g22 P-Spec 1 .5;27: TDLRSP 


page 5 


* 


Beams 


PROCESSED BEAM VELOCITIES 


* 

in lock 

1 

pbvX 


pbvY 


pbvZ 

1 

X 


Y 


z 

1 

Num 

■k 

none 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

■k 

1 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

1 

* 

2 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

2 

* 

3 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

4 

* 

4 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

0 

1 

8 

* 

1,2 

1 

0 

1 

(b[l]-b[2])/2 

1 

0 

1 

0 

1 

1 

1 

0 

1 

3 

* 

1,3 

1 

(b[l]+b[3])/2 

1 

0 

1 

0 

1 

1 

1 

0 

1 

0 

1 

5 

* 

1,4 

1 

0 

1 

0 

1 

(b[l]-b[4])/2 

1 

0 

1 

0 

1 

1 

1 

9 

* 

2,3 

1 

0 

1 

0 

1 

(b[2]-b[3])/2 

1 

0 

1 

0 

1 

1 

1 

6 

* 

2,4 

1 

(b[2]+b[4])/2 

1 

0 

1 

0 

1 

1 

1 

0 

1 

0 

1 

10 

★ 

if 

3,4 

1 

0 

1 

( b [ 4 ] -b [ 3 ] )/2 

1 

0 

1 

0 

1 

1 

1 

0 

1 

12 

■k 

1,2,3 

1 

(b[l]+b[3])/2 

1 

(b[l]-b[2])/2 

1 

(b[2]-b[3])/2 

1 

1 

1 

1 

1 

1 

1 

7 

* 

1,2,4 

1 

(b[2]+b[4])/2 

1 

(b [1] -b[2] )/2 

1 

{ b [ 1 ] -b [ 4 ] )/2 

1 

1 

1 

1 

1 

1 

1 

11 

★ 

1,3,4 

1 

(b[l]+b[3])/2 

1 

(b [4 ] -b[3] )/2 

1 

( b [ 1 ] -b [ 4 ] )/2 

1 

1 

1 

1 

1 

1 

1 

13 

★ 

it 

2,3,4 

1 

(b[2]+b[4])/2 

1 

(b[4]-b[3])/2 

1 

(b[2]-b[3])/2 

1 

1 

1 

1 

1 

1 

1 

14 

* 

1,2, 3, 4 

1 

a 

1 

b 

1 

c 

1 

1 

1 

1 

1 

1 

1 

15 


K-MATRIX 


Case 


* a) (b[l]+b[2]+b[3]+b[4])/4 

* b) (b[l]-b[2]-b[3]+b[4])/4 

* c) (b[l]+b[2]-b[3]-b[4])/4 


* Each of the 16 possible cases has been assigned a case number to 

* facilitate the description of the necessary processing. The case 

* number is found in the column labled "Case Number" in the table 

* above. 

* 


* Determine the case number value for the current processing. 

* Each of the four radar beams' state has been assigned a weight 

* value: beam 1: 1, beam 2: 2, beam 3: 4, beam 4: 8. The "case 

* number" is computed by summing the radar beams multiplied by their 

* their weight factors. 

*************************************************************************J 


state_case := TDLR_STATE [ 1 ] + 2*TDLR_STATE[2] + 
4*TDLR_STATE[3] + 8*TDLR_STATE[4] 

case state_case of 
0, 1, 2, 4, 8: 
pbvX := 0 
pbvY : = 0 
pbvZ := 0 

K_MATRIX [ 1 , 1, 0] := 0 
K_MATRIX[2, 2, 0] := 0 
K_MATRIX [ 3 , 3, 0] := 0 
end 

3: pbvX := 0 

pbvY := (bl-b2)/2 
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pbvZ := 0 

K_MATRIX [ 1 , 1, 0] := 0 

K_MATRIX[2, 2, 0] := 1 

K_MATRIX[3, 3, 0] := 0 

end 

5: pbvX := (bl+b3)/2 

pbvY : = 0 

pbvZ := 0 

K_MATRIX [ 1 , 1, 0] := 1 
K_MATRIX [ 2 , 2, 0] := 0 
K_MATRIX [ 3 , 3, 0] := 0 
end 

9: pbvX := 0 

pbvY := 0 

pbvZ := (bl-b4)/2 

K_MATRIX [ 1 / 1, 0] : = 0 
K_MATRIX [ 2 , 2, 0] : = 0 
K_MATRIX [ 3 , 3, 0] := 1 
end 

6: pbvX := 0 

pbvY := 0 

pbvZ := (b2-b3)/2 

K_MATRIX[1, 1, 0] := 0 

K_MATRIX[2, 2, 0] := 0 

K_MATRIX [ 3 , 3, 0] := 1 

end 

10: pbvX : = (b2+b4)/2 

pbvY : = 0 
pbvZ := 0 

K_MATRIX [ 1 , 1, 0] := 1 
K_MATRIX [ 2 , 2, 0] := 0 
K_MATRIX [ 3 , 3, 0] := 0 
end 

12: pbvX := 0 

pbvY := (b4-b3)/2 
pbvZ := 0 

K_MATRIX [ 1 , 1, 0] := 0 
K_MATRIX [ 2 , 2, 0] := 1 
K_MATRIX [ 3 , 3, 0] := 0 
end 

7: pbvX := (bl+b3)/2 

pbvY := (bl-b2)/2 
pbvZ := (b2-b3)/2 
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K_MATRIX [ 1 , 1, 0] : = 1 
K_MATRIX [ 2 ; 2, 0] := 1 
K_MATRIX [ 3 , 3, 0] := 1 
end 

11: pbvX := (b2+b4)/2 

pbvY := (bl-b2)/2 
pbvZ := (bl-b4)/2 

K_MATRIX [ 1 , 1, 0] := 1 
K_MATRIX[2, 2, 0] := 1 
K_MATRIX [ 3 , 3, 0] := 1 
end 

13: pbvX := (bl+b3)/2 

pbvY := (b4-b3)/2 
pbvZ := (bl-b4)/2 

K_MATRIX [ 1 , 1, 0] := 1 
K_MATRIX [ 2 , 2, 0] := 1 
K_MATRIX [ 3 , 3, 0] := 1 
end 

14: pbvX := (b2+b4)/2 

pbvY := (b4-b3)/2 
pbvZ := (b2-b3)/2 

K_MATRIX [ 1 ; 1, 0] := 1 
K_MATRIX [ 2 , 2, 0] := 1 
K_MATRIX [ 3 , 3, 0] := 1 
end 

15: pbvX := (bl+b2+b3+b4)/4 

pbvY := (bl-b2-b3+b4)/4 
pbvZ := (bl+b2-b3-b4)/4 

K_MATRIX [ 1 , 1, 0] := 1 
K_MATRIX [ 2 , 2, 0] := 1 
K_MATRIX [ 3 , 3, 0] := 1 
end 


* 3D) Convert "processed" beam velocities into body velocites. 

************************************************************************* J 


TDLR_VELOCITY [ 1 ] := pbvX / COS ( TDLR_ANGLES [ 1 ] ) 
TDLR_VELOCITY [ 2 ] := pbvY / cos (TDLR_ANGLES [2] ) 
TDLR_VELOCITY [ 3 ] := pbvZ / cos ( TDLR_ANGLES [ 3 ] ) 

(*** where cos represents the cosine function. ***) 

END P_SPEC 
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NAME: 

1.6;18 

TITLE: 

TDSP 

INPUT/OUTPUT: 

TD_COUNTER : datajn 
TDS_STATUS : datajn 
TD_SENSED :data_out 

TDS_STATUS : data_out 

BODY: 

BEGIN P_SPEC 

* TDSP -- Touch Down Sensor Processing 

★ 

* TDSP processing is responsible for: 

* 1) Determining the operational status of the touch down sensor, and 

* 2) determining if touch down has been sensed. 

* 1) Determining the operational status of the touch down sensor. 

* and 2) determining if touch down has been sensed. 

* 

* The data element TD_COUNTER represents the sensor's measurement. 

* There are only two valid sensor measurements: A) all bits set 

* which indicates touch down is sensed, and B) all bits clear which 

* indicates touch down is not sensed. If a valid sensor value 

* exists, then the operation status of the touch down sensor is 

* reported as "healthy" (value 0). Any other value of TD_COUNTER 

* indicates a faulty sensor in which case the touch down sensor 

* status is reported as "failed" (value 1). 

* 

* Note, once the touch down sensor has been determined to be 

* faulty, it is considered to be failed for the duration of the 

* mission --no processing occurs once the sensor has failed. 

* 

* The notation 'Oxdddd' represents a hexadecimal value 


if ( TDS_STATUS = 0) then (* healthy sensor *) 

if (TD_COUNTER = 0) then 

TD_SENSED := 0 (* TD not sensed *) 

else if ( TD_COUNTER = OxFFFF) then 

TD_SENSED := 1 (* TD sensed *) 

else (* faulty sensor *) 

TD_SENSED : = 0 

TDS_STATUS := 1 (* failed sensor *) 
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end if 
end if 
END P_SPEC 
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NAME: 

1.7;21 

TITLE: 

TSP 

INPUT/OUTPUT: 

Ml : datajn 

M2 : datajn 

M3 : datajn 

M4 : datajn 

SS_TEMP : datajn 

T1 : datajn 

T2 : datajn 

T3 : datajn 

T4 : datajn 

THERMO_TEMP : datajn 
ATMOSPHERIC_TEMP : data_out 
TS_STATUS : data_out 

BODY: 

BEGIN P_SPEC 

{ *********************************************************************** 

* TSP -- Temperature Sensor Processing 

* 

* TSP is responsible for: 

* 1) Ascertaining the operational status of the temperature sensors, and 

* 2) Determining the current atmospheric temperature based on the 

* measurements provided by two on-board temperature sensors. 

* 

* Notes: 

* o The constants associated with the solid state temperature sensor 

* and the thermocouple pair would normally be calculated once and 

* re-used in subsequent calls to this routine. However, the GCS 

* experiment methodology requires it to be calculated each call. 

*********************************************************************** j 


(*********************************************************************** 

* 1) Determine the operational status of the temperature sensors 

*********************************************************************** j 


(*** The status of both sensors is always reported as HEALTHY ***) 
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TS_STATUS [ 1 ] := 0 
TS_STATUS [ 2 ] := 0 

^*********************************************************************** 

* 2A) Compute the temperature based on the solid state sensor 

***********************************************************************J 


solid-state-temp := 

( (T2 - T1)/(M2 - Ml)) * SS_TEMP + Tl - ((T2 - T1)/(M2 - Ml)) * Ml 
Implementation note, if Ml := M2 a divide by zero exception must be handled. 

( *********************************************************************** 

* 2B) Determine if the temperature is within the valid range of the 

* TC sensor; 

***********************************************************************J 

lower-parabolic- function := 

-(x - (M3 + ( ( (T4 - T3)/(M4 - M3))/2))) A 2 + (T3 + ( ( (T4 - T3)/(M4 - M3))/2) A 2) 

^***************************^******************************************* 

* Once the function describing the parabola has been determined, the 

* temperature representing the lower limit of the parabolic region can 

* be determined. The lower limit of the lower parabolic region is 

* specified as 15% of the difference of the two calibration 

* measurements less than the lower calibration point. 

* ★★★**★★****★★★*★★***★*★**★*★*★*★*★★★★★★*★★******★★★★★★★★★**********★★•* J 

lower-parabolic-temp-limit := lower-parabolic- function (M3 - 0.15*(M4 - M3)) 

(*** define the upper parabolic function ***) 
upper-parabolic-function := 

(X - (M4 - ( ( (T4 - T3)/(M4 - M3))/2))) A 2 + (T4 - ( ( (T4 - T3)/(M4 - M3))/2) A 2) 

^*********************************************************************** 

* Once the function describing the parabola has been determined, the 

* temperature representing the upper limit of the parabolic region can 

* be determined. The upper limit of the upper parabolic region is 

* specified as 15% of the difference of the two calibration 

* measurements greater than the upper calibration point. 

***********************************************************************J 

upper-parabolic-temp- limit := upper-parabolic-function(M4 + 0 . 15* (M4 - M3)) 


(*********************************************************************** 

* Now determine sensor temperature measurement to report 

***********************************************************************J 

if (solid-state-temp < lower-parabolic-temp-limit) OR {1} 

(solid-state-temp > upper-parabolic-temp-limit) then 

(*** the atmospheric temp is beyond the valid range of the TC sensor 

so return the solid-state-temp ***) 

ATM0SPHERIC_TEMP := solid-state-temp 
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else {1} 

* 2C) Compute the temperature based on the TC sensor 

★ ★★★★****************************************************************** J 

if (THERMOJTEMP < M3) then {2} 

(*** the atmospheric temp resides within the TC lower parabolic region ***) 
ATMOSPHERIC JTEMP := lower -parbolic-f unction (THERMOJTEMP) 
else if (THERMOJTEMP > M4) then {2} 

(*** the atmospheric temp resides within the TC upper parabolic region ***) 
ATMOSPHERIC JTEMP := upper-parabolic-function(THERMOJTEMP) 
else {2} 

(*** The temperature resides within the TC sensor linear region ***) 

(*** compute the temperature from the TC linear region ***) 

ATMOSPHERICJTEMP := 

( (T4 - T3)/(M4 - M3)) * THERMOJTEMP + T3 - ( ( T4 - T3)/(M4 - M3)) * M3 


end if 

(2) 

end if 

{1} 

END P_SPEC 
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NAME: 

1.8;51 

TITLE: 

CP 

INPUT/OUTPUT: 

AE_CMD : datajn 

AE_STATUS : datajn 

AE_TEMP : datajn 
AR_ALTITUDE : datajn 

AR_STATUS: datajn 

ATMOSPHERIC_TEMP : datajn 

A_ACCELERATION : datajn 

A_STATUS : datajn 

CHUTE_RELEASED : datajn 

COMM_SYNC_PATTERN : datajn 

CONTOUR_CROSSED : datajn 

C_STATUS :datajn 

FRAME_COUNTER : datajn 

GP_ALTITUDE : datajn 

GP_ATTITUDE : datajn 

GP_PHASE : datajn 

GP_ROTATION : datajn 

GP_VELOCITY : datajn 

G_ROTATION : datajn 

G_STATUS : datajn 

K_ALT : datajn 

KJVIATRIX : datajn 

PEJNTEGRAL : datajn 

RE_CMD : datajn 

RE STATUS : data in 
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SUBFRAME_COUNTER : datajn 
TDLR_STATE : datajn 
TDLR_STATUS : datajn 
TDLR_VELOCITY : datajn 
TDS_STATUS : datajn 
TD_SENSED : datajn 
TEJNTEGRAL : datajn 
TS_STATUS : datajn 
VELOCITY_ERROR : datajn 
YEJNTEGRAL : datajn 
C_STATUS : data_out 
PACKET :data_out 

BODY: 

BEGIN P_SPEC 

Note, bubbles 1.8, 2.3, 3.5 and the associated P-Specs represent a single 
process, CP described below. 

* CP -- Communications Processing 

* 

* CP processing is responsible for: 

* 1) determining the current operational status of the communicator, and 

* 2) constructing a telemetry data packet. 

* 

* CP processing is responsible for constructing a data packet 

* suitable for transmission via the on-board communications 

* equipment. The data element PACKET contains 512 bytes of storage 

* in which to construct the data packet. Conceptually, the data 

* packet is merely the organization of particular data into the 

* storage defined by PACKET. 

* 

* A data packet is organized into five fields arranged in the 

* following sequence: a syncronization pattern, a sequence number, 

* a data mask, a data field, and a checksum. Constructing a data 

* packet consists of updating the five fields with the appropriate 

* data. 

* 

* CP has the capability to construct three specific types of 

* data packets, one each for reporting the completion of each 

* subframe. The distinguishing element of each packet type is 

* the contents of the data field and indirectly the value of the 

* data mask. The data field is a composite 
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* field consisting of the values of specific data elements which 

* were potentially altered during the processing of the specified 

* subframe. 

* 

* The contents of the data field of a specific data packet is 

* indicated by the data packet's data mask. The data mask is a 

* 32-bit field. Each of the 32 data elements which may be reported 

* in the data packet has an associated bit in the data mask. A set 

* bit in the data mask indicates that the associated data element 

* is stored in the data field portion of the data packet. 

* 

* At the completion of sensor processing subframe, the data field 

* contains the data elements listed below in the order listed. 

* Note the list of data elements below contains the derivation 

* of the data mask value and derivation of the data field length, 

* in bytes, which is used in contructing the packet. The 

* synchronization pattern, sequence number, and data mask 

* consume 7 bytes. 

* 

* data element data field length 

* name bit mask in bytes 

* 

* AR_ALTITUDE 0x10000000 8 

* AR_STATUS 0x08000000 1 

* ATMOSPHERICJTEMP 0x04000000 8 122 bytes in this field 

* A_ACCELERATION 0x02000000 24+7 bytes in preceeding fields 

* A_STATUS 0x01000000 3 

* C_STATUS 0x00200000 1 129 bytes not including 

* G_ROTATION 0x00008000 24 the checksum 

* G_STATUS 0x00004000 1 

* K_ALT 0x00002000 4 

* K_MATRIX 0x00001000 12 

* TDLR.STATE 0x00000100 4 

* TDLR_STATUS 0x00000080 4 

* TDLR_VELOCITY 0x00000040 24 

* TDS.STATUS 0x00000020 1 

* TD_SENSED 0x00000010 1 

* TS_STATUS 0x00000004 2 

* 122 bytes 

* 

* 0xlF20FlF4 data mask value for subframe #1 

* 

* At the completion of guidance processing subframe, the data field 

* contains the following data elements: 

* 

* data element data field length 

* name bit mask in bytes 

* 

* CONTOUR_CROSSED 0x00400000 1 

* C.STATUS 0x00200000 1 

* GP.ALTITIUDE 0x00100000 8 166 bytes in this field 

* GP_ATTITUDE 0x00080000 72+7 bytes in preceeding fields 

* GP_PHASE 0x00040000 4 

* GP_ROTATION 0x00020000 48 173 bytes not including 

* GP_VELOCITY 0x00010000 24 the checksum 

* VELOCITY_ERROR 0x00000002 8 
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* 166 bytes 

* 

* 0x007F0002 data mask value for subframe #2 

* 

* At the completion of control law processing subframe, the data field 

* contains the following data elements: 

* 


★ 

data element 

data 

field length 

★ 

* 

name 

bit mask 

in bytes 


* 

AE_CMD 

0x80000000 

6 


★ 

AE_STATUS 

0x40000000 

1 


* 

AE_TEMP 

0x20000000 

2 

38 bytes in this field 

* 

CHUTE_RELEASED 

0x00800000 

1 + 

7 bytes in preceeding fields 

★ 

C_STATUS 

0x00200000 

1 

... 

* 

PE_INTEGRAL 

0x00000800 

8 

45 bytes not including 

* 

RE_CMD 

0x00000400 

2 

the checksum 

* 

RE_STATUS 

0x00000200 

1 


* 

TE_INTEGRAL 

0x00000008 

8 


★ 

YE_INTEGRAL 

0x00000001 

8 


* 



38 bytes 



* 


* 0xE0A00E09 data mask value for subframe #3 

* 

* It is not obvious why the checksum field is defined in three 

* places in the data structures presented below. Notice that the 

* data field is variable in length. The organization of the data 

* packet demands that the checksum field immediately follow the 

* last byte of the data field. In order to satisfy this 

* requirement, storage for the checksum field is defined as the 

* last element in each of the data field specifications. 

* 

* A function for computing the CRC-16 for a data packet is defined 

* below. The function takes two arguments, the address of the byte 

* stream to process and integer specifing the length of the byte 

* stream. The function returns an integer value which is the 

* CRC-16 of the specified byte stream. 

************************************************************************J 


(*** the Sensor Processing subframe data field and checksum ***) 
type sp_data_t Record 


AR_ALTITUDE 

quadword 

AR_STATUS 

byte 

ATMOSPHERIC_TEMP 

quadword 

A_ACCELERATION 

array[1..3] of quadword 

A_STATUS 

array [1. .3] of byte 

C_STATUS 

byte 

G_ROTATION 

array[1..3] of quadword 

G_STATUS 

byte 

K_ALT 

longword 

K_MATRIX 

array[1..3] of longword 

TDLR_STATE 

array [1. .4] of byte 

TDLR_STATUS 

array [1. .4] of byte 

TDLR_VELOCITY 

array [1.. 3] of quadword 

TDS_STATUS 

byte 
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TD_SENSED 
TS_STATUS 
CHECKSUM 
end {record} 


byte 

array [1. .2] of byte 
word 


(*** the Guidance Processing subframe data field and checksum ***) 
type gp_data_t record 


C0NT0UR_CR0SSED 

byte 

C_STATUS 

byte 

gp_altitiude 

quadword 

GP_ATTITUDE 

array [1.. 9] of quadword 

GP_PHASE 

longword 

GP_R0TATI0N 

array[1..6] of quadword 

GP_VEL0CITY 

array[1..3] of quadword 

VELOCITY_ERROR 

quadword 

CHECKSUM 

word 


end {record} 


(*** the Control Law Processing subframe data field and checksum ***) 
type clp_data_t record 


AE_CMD 

array [1. .3] of word 

AE_STATUS 

byte 

AE_TEMP 

word 

CHUTE_RELEASED 

byte 

C_STATUS 

byte 

PE_INTEGRAL 

quadword 

RE_CMD 

word 

RE_STATUS 

byte 

TE_INTEGRAL 

quadword 

YE_INTEGRAL 

quadword 

CHECKSUM 

word 


end {record} 


(*** the data packet structure ***) 


type subframe_t = (sp_data_t, gp_data_t, clp_data_t) 


type data_packet_t = record 

SYNC_PATTERN : word 

SEQ_NUMBER : byte 

DATA_MASK : longword 


case subframe_t of 

sp : sp_data_t 

I UP : gp_data_t 

I clp : clp_data_t 

end 

end {record} 


(************************************************************************* 

* Overlay the data element PACKET with the data structure data_packet_t 

* and refer to it as "data_packet" for local processing. 

************************************************************************ j 

(*** declare a variable of type pointer to data_packet_t ***) 
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var data_packet : @data_packet_t 

data_packet@ := PACKET (* new variable "points to" PACKET *) 

^ ******** ★★★**★**★★★**★**★***★**★★★*★★★★★**★★★***★* 

* 1) Determine the current operational status of the communicator. 

* 

* The operational status of the communicator is always reported 

* as "healthy" (value 0). 

C.STATUS := 0 

* 2) Construct a telemetry data packet. 


^************************** ******* *************************************** 

* 2A) Get synchronization pattern. 

★ 

* The leading field is the synchronization pattern. This 16-bit 

* pattern allows the recieving communications gear to recognize 

* the beginning of the data packet. The bit pattern is stored in 

* the data element COMM_SYNC_PATTERN. 

data_packet . SYNC_PATTERN := COMM_SYNC_PATTERN 

* 2B) Determine the sequence number. 

* 

* The sequence number is an unsigned 8 -bit value. Conceptually, 

* the sequence number performs as an 8 -bit counter. The initial 

* packet is assigned a value of zero and the counter incremented 

* for each packet thereafter. However, an implementation does not 

* have access to it's own inter- subframe static storage, so the 

* "counter" is implemented as a function of the current frame 

* number and subframe number. 

★★★*********************************************************************j 

data_packet . SEQ_NUMBER := (3*(FRAME_C0UNTER-1)+(S0BFRAME_C0UNTER-1) ) MOD 256 
where MOD represents modulo division operation 




* 2C) Prepare the data mask, 

* 2D) Prepare the data, and 

* 2E) Compute the checksum. 


************************************************************************| 


if ( SUBFRAME_COUNTER == 1) then (* sp *) 

data_packet . DATA_MASK := 0xlF20FlF4 

data_packet . DATA . SP . AR_ALTITUDE := AR_ALTITUDE [ 0 ] 
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data_packet . DATA . SP . AR_STATUS 
data_packet . DATA . SP . ATMOSPHERIC_TEMP 
data_packet . DATA . SP . A_ACCELERATION [ 1 ] 
data_packet . DATA . SP . A_ACCELERATION [ 2 ] 
data_packet . DATA . SP . A_ACCELERATION [ 3 ] 
data_packet . DATA . SP . A_STATUS [ 1 ] 
data_packet . DATA . SP . A_STATOS [ 2 ] 
data_packet . DATA . SP . A_STATUS [ 3 ] 
data_packet . DATA . SP . C_STATDS 
data_packet . DATA . SP . G_ROTATION [ 1 ] 
data_packet . DATA . SP . G_ROTATION [ 2 ] 
data_packet . DATA . SP . G_ROTATION [ 3 ] 
data_packet . DATA . SP . G.STATUS 
data_packet . DATA . SP . K_ALT 
data_packet . DATA . SP . K_MATRIX [ 1 ] 
data_packet . DATA . SP . K_MATRIX [ 2 ] 
data_packet . DATA . SP . K_MATRIX [ 3 ] 
data_packet . DATA . SP . TDLR_STATE [ 1 ] 
data_packet . DATA . SP . TDLR_STATE [ 2 ] 
data_packet . DATA . SP . TDLR_STATE [ 3 ] 
data_packet . DATA . SP . TDLR_STATE [ 4 ] 
data_packet . DATA . SP . TDLR_STATUS [ 1 ] 
data_packet . DATA . SP . TDLR_STATUS [ 2 ] 
data_packet . DATA . SP . TDLR_STATUS [ 3 ] 
data_packet . DATA . SP . TDLR_STATUS [ 4 ] 
data_packet . DATA . SP . TDLR_VELOCITY [ 1 ] 
data_packet . DATA . SP . TDLR.VELOCITY [ 2 ] 
data_packet . DATA . SP . TDLR_VELOCITY [ 3 ] 
data_packet . DATA . SP . TDS_STATUS 
data_packet . DATA . SP . TD_SENSED 
data_packet . DATA . SP . TS_STATDS [ 1 ] 
data_packet . DATA . SP . TS_STATUS [ 2 ] 
data_packet . DATA . SP . CHECKSUM 


= AR_STATUS [0] 

= ATMOSPHERIC_TEMP 
= A_ACCELERATION [1,0] 

= A_ACCELERATION [2,0] 

= A_ACCELERATION [3,0] 

= A_STATUS[1,0] 

= A_STATUS[2,0] 

= A_STATUS [3,0] 

= C_STATUS 
= G_ROTATION[1,0] 

= G_ROTATION[2, 0] 

= G_ROTATION[3, 0] 

= G_STATUS 
= K_ALT [ 0 ] 

= K_MATRIX [1,1/0] 

= K_MATRIX[2,2,0] 

= K_MATRIX [3,3,0] 

= TDLR_STATE [ 1 ] 

= TDLR_STATE [ 2 ] 

= TDLR_STATE [ 3 ] 

= TDLR_STATE [ 4 ] 

= TDLR_STATUS [1] 

= TDLR_STATUS [2] 

= TDLR_STATUS[3] 

= TDLR_STATUS [4] 

= TDLR_VELOCITY [1,0] 

= TDLR_VELOCITY[2, 0] 

= TDLR_VELOCITY [3,0] 

= TDS_STATUS 
= TD_SENSED 
= TS_STATUS [1] 

= TS_STATUS [ 2 ] 

= CRC16 ( data_packet . DATA . SP , 129) 


else if ( SUBFRAME_COUNTER == 2) then 
data_packet . DATA_MASK := 0x007F0002 


(* gp *) 


data_packet . DATA . GP . CONTOUR_CROSSED 
data_packet . DATA . GP . C_STATUS 
data_packet . DATA . GP . GP_ALTITUDE 


= CONTOUR_CROSSED 
= C_STATUS 
= GP_ALTITUDE[0] 


(*** first element of array changes most rapidly ***) 


data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 
data_packet . DATA . GP . GP_ATTITUDE 

data_packet . DATA . GP . GP_PHASE 


[1] 

= GP_ATTITUDE[1, 1, 0] 

[2] 

= GP_ATTITUDE[2, 1, 0] 

[3] 

= GP_ATTITUDE[3, 1, 0] 

[4] 

= GP_ATTITUDE[1, 2, 0] 

[5] 

= GP_ATTITUDE[2, 2, 0] 

[6] 

= GP_ATTITUDE[3, 2, 0] 

[7] 

= GP_ATTITUDE[1, 3, 0] 

[8] 

= GP_ATTITUDE[2, 3, 0] 

[9] 

= GP_ATTITUDE [ 3 , 3, 0] 


= GP_PHASE 


data_packet . DATA . GP . GP_ROTATION [ 1 ] 


:= GP_ROTATION [ 2 , 1] 
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data_packet . DATA . GP . GP_ROTATION [ 2 ] 
data_packet . DATA . GP . GP_ROTATION [ 3 ] 
data_packet . DATA . GP . GP_ROTATION [ 4 ] 
data_packet . DATA . GP . GP_ROTATION [ 5 ] 
data_packet . DATA . GP . GP_ROTATION [ 6 ] 

data_packet . DATA . GP . GP_VELOCITY [ 1 ] 
data_packet . DATA . GP . GP_VELOCITY [ 2 ] 
data_packet . DATA . GP . GP_VELOCITY [ 3 ] 

data_packet . DATA . GP . VELOCITY_ERROR 
data_packet . DATA . GP . checksum 

else 

data_packet.DATA_MASK : = 0xE0A00E09 

data_packet . DATA . CLP . AE_CMD [ 1 ] 
data_packet . DATA . CLP . AE_CMD [ 2 ] 
data_packet . DATA . CLP . AE_CMD [ 3 ] 
data_packet . DATA . CLP . AE_STATDS 
data_packet . DATA . CLP . AE_TEMP 
data_packet . DATA . CLP . CHUTE_RELEASED 
data_packet . DATA . CLP . C_STATUS 
data_packet . DATA . CLP . PE_INTEGRAL 
data_packet . DATA . CLP . RE_CMD 
data_packet . DATA . CLP . RE_STATUS 
data_packet . DATA . CLP . TE_INTEGRAL 
data_packet . DATA . CLP . YE_INTEGRAL 
data_packet . DATA . CLP . CHECKSUM 

end if 


:= GP_R0TATI0N[3, 1] 

:= GP_R0TATI0N[1, 2] 

: = GP_R0TATI0N[3, 2] 

:= G P_ROT AT I ON [ 1 , 3] 

:= GP_ROTATION[2, 3] 

:= GP_VELOCITY [ 1 , 0] 

:= GP_VELOCITY [ 2 , 0] 

:= GP_VELOCITY[3, 0] 

:= VELOC I T Y_ERROR 

:= CRC1 6 ( data_packet . DATA . GP , 173) 

(* clp *) 


= AE_CMD [ 1 ] 

= AE_CMD [ 2 ] 

= AE_CMD [ 3 ] 

= AE_STATUS 
= AE_TEMP 
= CHUTE_RELEASED 
= C_STATUS 
= PE_INTEGRAL 
= RE_CMD 
= RE_STATUS 
= TE_INTEGRAL 
= YE_INTEGRAL 

= CRC16(data_packet. DATA. CLP, 45) 


return 


^************************************************************************ 

* Title: CRC16 

* Description: 

* Compute the Cyclic Redundancy Code of the specified buffer using 

* CRC-16 as the generator polynomial. 

* Arguments: 

* byte pointer buffer - address of first byte of message. 

* longword length - count of bytes in message. 

* 

* Returns: 

* word crc - the CRC-16 of the specified message. 

************************************************************************J 


(************************************************************************ 

* The following CRC generation algorithm is described by Perez in 

* IEEE Micro, Volume 3, Number 3 (june 1983). 

* 

* The algorithm computes the CRC of the specified messages by 

* operating on a byte at a time. Beginning with an initial value 

* for the CRC, each byte of the message in sequence is applied to 

* the computation of the new CRC value. 

* 
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* In the bitwise approach to generating a CRC, Each bit within the 

* message is operated on individually. Note, that after performing the 

* necessary bitwise operations on 8 successive bits, there are only 

* 256 possible distinct results. This algorithm takes advantage of 

* this fact and operates on a single byte (8-bits) at time. 

* 

* For a given 17-bit generator polynomial a 256 (16-bits) entry 

* table is constructed for storing the polynomial "signature." 

* The contents of this table is used for processing the message. 

* An algorithm for constructing the table is presented in the reference 

* cited above. 

*****★*****★★★*★*****★★★•*•★***************★★★■*•**★******★★★•*•★**★★*******★* J 


(*** The "signature" table for the CRC-16 generator polynomial OxlAOOl ***) 


word crcl6_table[0. .255] 
0x0000, OxcOcl, 

0xcl81, 

0x0140, 

0xc301, 

0x03c0, 

0x0280, 

0xc241, 

0xc601, 

0x06c0, 

0x0780, 

0xc741, 

0x0500, 

0xc5cl, 

0xc481, 

0x0440, 

OxccOl, 

OxOccO, 

0x0d80, 

0xcd41, 

OxOfOO, 

Oxcfcl, 

0xce81, 

0x0e40, 

OxOaOO, 

Oxcacl, 

0xcb81, 

0x0b40, 

0xc901, 

0x09c0, 

0x0880, 

0xc841, 

0xd801, 

0xl8c0, 

0x1980, 

0xd941, 

OxlbOO, 

Oxdbcl, 

0xda81, 

0xla40, 

OxleOO, 

Oxdecl, 

0xdf81, 

0xlf40, 

OxddOl, 

OxldcO, 

0xlc80, 

0xdc41, 

0x1400, 

0xd4cl, 

0xd581, 

0x1540, 

0xd701, 

0xl7c0, 

0x1680, 

0xd641, 

0xd201, 

0xl2c0, 

0x1380, 

0xd341, 

0x1100, 

Oxdlcl, 

0xd081, 

0x1040, 

OxfOOl, 

0x30c0, 

0x3180, 

0xfl41, 

0x3300, 

0xf3cl, 

0xf281, 

0x3240, 

0x3600, 

0xf6cl, 

0xf781, 

0x3740, 

0xf501, 

0x35c0, 

0x3480, 

0xf441, 

0x3c00, 

Oxfccl, 

0xfd81, 

0x3d40, 

OxffOl, 

0x3fc0, 

0x3e80, 

0xfe41, 

OxfaOl, 

Ox3acO, 

0x3b80, 

0xfb41, 

0x3900, 

0xf9cl, 

0xf881, 

0x3840, 

0x2800, 

0xe8cl, 

0xe981, 

0x2940, 

OxebOl, 

0x2bc0, 

0x2a80, 

0xea41, 

OxeeOl, 

0x2ec0, 

0x2f80, 

0xef41, 

0x2d00, 

Oxedcl, 

0xec81, 

0x2c40, 

0xe401, 

0x24c0, 

0x2580, 

0xe541, 

0x2700, 

0xe7cl, 

0xe681, 

0x2640, 

0x2200, 

0xe2cl, 

0xe381, 

0x2340, 

OxelOl, 

0x21c0, 

0x2080, 

0xe041, 

OxaOOl, 

0x60c0, 

0x6180, 

0xal41, 

0x6300, 

0xa3cl, 

0xa281, 

0x6240, 

0x6600, 

0xa6cl, 

0xa781, 

0x6740, 

0xa501, 

0x65c0, 

0x6480, 

0xa441, 

Ox6cOO, 

Oxaccl, 

0xad81, 

0x6d40, 

OxafOl, 

0x6fc0, 

0x6e80, 

0xae41, 

OxaaOl, 

0x6ac0, 

0x6b80, 

0xab41, 

0x6900, 

0xa9cl, 

0xa881, 

0x6840, 

0x7800, 

0xb8cl, 

0xb981, 

0x7940, 

OxbbOl, 

Ox7bcO, 

0x7a80, 

0xba41, 

OxbeOl, 

0x7ec0, 

0x7f80, 

0xbf41, 

0x7d00, 

Oxbdcl, 

0xbc81, 

0x7c40, 

0xb401, 

0x74c0, 

0x7580, 

0xb541, 

0x7700, 

0xb7cl, 

0xb681, 

0x7640, 

0x7200, 

0xb2cl, 

0xb381, 

0x7340, 

OxblOl, 

0x71c0, 

0x7080, 

0xb041, 

0x5000, 

0x90cl, 

0x9181, 

0x5140, 

0x9301, 

0x53c0, 

0x5280, 

0x9241, 

0x9601, 

0x56c0, 

0x5780, 

0x9741, 

0x5500, 

0x95cl, 

0x9481, 

0x5440, 

0x9c01, 

0x5cc0, 

0x5d80, 

0x9d41, 

Ox5fOO, 

0x9fcl, 

0x9e81, 

0x5e40, 

0x5a00, 

0x9acl, 

0x9b81, 

0x5b40, 

0x9901, 

0x59c0, 

0x5880, 

0x9841, 

0x8801, 

0x48c0, 

0x4980, 

0x8941, 

0x4b00, 

0x88cl, 

0x8a81, 

0x4a40, 

0x4e00, 

0x8ecl, 

0x8f81, 

0x4f40, 

0x8d01, 

0x4dc0, 

0x4c80, 

0x8c41, 

0x4400, 

0x84cl, 

0x8581, 

0x4540, 

0x8701, 

0x47c0, 

0x4680, 

0x8641, 

0x8201, 

0x42c0, 

0x4380, 

0x8341, 

0x4100, 

0x81cl, 

0x8081, 

0x4040 


(*** crc is a 16-bit unsigned integer value ***) 

crc := 0 (* initial crc value *) 

(*** process every byte in the message ***) 
do next_byte := 1 to bytecount 
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crc XOR next_byte (* bitwise exclusive OR the lower 8 bits of crc *) 

crc » 8 (* bitwise right shift crc 8 times *) 

crc XOR crcl6_table [ index] (* bitwise exclusive OR all 16 bits of crc *) 


return crc 
END P_SPEC 


index := 
crc : = 
crc :« 
end do 
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Guidance Processing Subframe 


•out ‘PACKET 



EXTERNAL 
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PAT - Guidance Processing Subframe 


SUBFRAME_COUNTER 


"GCS_SIM_RENDEZVOUS" 

"GP” 

"CP" 






tig” 


1 

2 
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NAME: 

2.1 ;4 

TITLE: 

GCS_SIM_RENDEZVOUS 

INPUT/OUTPUT: 
SENSOR_OUTPUT : datajn 
GUIDANCE_STATE : datajn 
EXTERNAL : datajn 
RUN_PARAMETERS : datajn 
RUN_PARAMETERS : data_out 
SENSOR_OUTPUT : data_out 
EXTERNAL : data_out 
PACKET: data_out 
GUIDANCE STATE : data out 


BODY: 

BEGIN P-Spec 


GCS_SIM_RENDEZVOUS provides the interface to the vehicle. This module is provided by 
the systems group. 


Bubbles 1.1, 2.1, 3.1 and the associated P-Specs represent a single process. 


END P-Spec 
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NAME: 

2.2;47 

TITLE: 

GP 

INPUT/OUTPUT: 

A_ACCELERATION : datajn 

AE_SWITCH : datajn 

AE_TEMP : datajn 

AR_ALTITUDE : datajn 

CHUTE_RELEASED : datajn 

CL : datajn 

CONTOUR_ALTITUDE : datajn 
CONTOUR_CROSSED : datajn 
CONTOUR_VELOCITY : datajn 
DELTA_T : datajn 
DROP_HEIGHT : datajn 
DROP_SPEED : datajn 
ENGINES_ON_ALTITUDE : datajn 
FRAME_COUNTER : datajn 
GP_ALTITUDE : datajn 
GP_ATTITUDE : datajn 
GP_PHASE : datajn 
GP_VELOCITY : datajn 
GRAVITY : datajn 
G_ROTATION : datajn 
K_ALT : datajn 
K_MATRIX : datajn 
MAX_NORMAL_VELOCITY : datajn 
RE_SWITCH : datajn 
TD SENSED : data in 
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TDLR_VELOCITY : datajn 
TDS_STATUS : datajn 
AE_SWITCH : data_out 
CL : dataout 

CONTOUR_CROSSED : data_out 
FRAME_ENGINESJGNITED : data_out 
GP_ALTITUDE : data_out 
GP_ATTITUDE : data_out 
GP_PHASE : data_out 
GP_ROTATION : data out 
GP_VELOCITY : data_out 
RE_SWITCH : data_out 
TEJNTEGRAL : data_out 
VELOCITY_ERROR : data_out 


BODY: 

BEGIN P_SPEC 

^************************************************************************ 

* GP -- Guidance Processing 

•k 

* GP is responsible for: 

* 1) Maintaining the history of the vehicle's altitude, velocities, 

* and attitude, 

* 2) Computing the current vehicle altitude, velocities and attitude, 

* 3) Determining if the engines should be switched on or off, 

* 4) Computing the current velocity error, 

* 5) Determining if the predetermined velocity- altitude contour has 

* been crossed, 

* 6) Determining the current guidance phase, and 

* 7) Determining the appropriate axial engine control law parameters. 

************************************************************************J 


(************************************************************************ 

* 1) Maintain the history of the vehicle altitude, velocities, 

* and attitude by "rotating variables." 

* 

* The data element GP_ALTITUDE is defined as a single dimensional 

* array. The data element GP_VELOCITY is defined as a two 

* dimensional array. The first dimension of GP_VELOCITY represents 

* a vehicle axis: x-axis (1), y-axis (2), z-axis (3). The data 
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* element GP_ATTITUDE is defined as a three dimensional array 

* (1..3, 1..3, 0..4). The vehicle attitudes are arranged as a 3x3 

* matrix, represented by the first two dimensions of GP_ATTITUDE . 

* The first dimension of GP_ALTITUDE, the second dimension of 

* GP_VEL0CITY and the third diminsion of GP_ATTITUDE represent a 

* history. Each history is five deep. The first element of each 

* history, element zero, holds the most recently computed value. 

* The last element of each history, element four holds the oldest 

* maintained value. In shifting the values stored in these data 

* elements, a multi -frame history is maintained. 
************************************************************************ ) 

GP_ALTIT0DE[4] := GP_ALTITUDE[3] 

GP_ALTITUDE[3] := GP_ALTITUDE[2] 

GP_ALTITUDE[2] := GP_ALTITUDE[1] 

GP_ALTITUDE[1] := GP_ALTITUDE[0] 

GP_VEL0CITY [1, 4] := GP_VEL0CITY[1, 3] 

GP_VEL0CITY [1 , 3] := GP_VEL0CITY[1, 2] 

GP_VEL0CITY[1, 2] := GP_VEL0CITY[1, 1] 

GP_VEL0CITY[1, 1] := GP_VEL0CITY[1, 0] 

GP_VEL0CITY[2, 4] := GP_VELOCITY [ 2 , 3] 

GP_VEL0CITY[2, 3] := GP_VEL0CITY [ 2 , 2] 

GP_VEL0CITY[2, 2] := GP_VEL0CITY[2, 1] 

GP_VEL0CITY[2, 1] := GP_VEL0CITY[2, 0] 

GP_VELOCITY [ 3 , 4] := GP_VELOCITY [ 3 , 3] 

GP_VEL0CITY[3, 3] := GP_VEL0CITY[3, 2] 

GP_VELOCITY [ 3 , 2] := GP_VEL0CITY[3, 1] 

GP_VELOCITY [ 3 , 1] := GP_VELOCITY [ 3 , 0] 

GP_ATTITUDE[1, 1, 4] := GP_ATTITUDE [ 1 , 1, 3] 

GP_ATTITUDE[1, 2, 4] := GP_ATTITUDE [ 1 , 2, 3] 

GP_ATTITUDE[1, 3, 4] := GP_ATTITUDE [ 1 , 3, 3] 

GP_ATTITUDE[2, 1, 4] := GP_ATTITUDE [ 2 , 1, 3] 

GP_ATTITUDE[2, 2, 4] := GP_ATTITUDE [ 2 , 2, 3] 

GP_ATTITUDE[2, 3, 4] := GP_ATTITUDE[2, 3, 3] 

GP_ATTITUDE [ 3 , 1, 4] := GP_ATTITUDE [ 3 , 1, 3] 

GP_ATTITUDE[3, 2, 4] := GP_ATTITUDE [ 3 , 2, 3] 

GP_ATTITUDE [ 3 , 3, 4] := GP_ATTITUDE [ 3 , 3, 3] 

GP_ATTITUDE[1, 1, 3] := GP_ATTITUDE[1, 1, 2] 

GP_ATTITUDE[1, 2, 3] := GP_ATTITUDE[1, 2, 2] 

GP_ATTITUDE[1, 3, 3] := GP_ATTIT0DE[1, 3, 2] 

GP_ATTITUDE[2, 1, 3] := GP_ATTITUDE[2, 1, 2] 

GP_ATTITUDE[2, 2, 3] := GP_ATTITUDE[2, 2, 2] 

GP_ATTITUDE[2, 3, 3] := GP_ATTITUDE[2, 3, 2] 

GP_ATTITUDE[3, 1, 3] := GP_ATTITUDE[3, 1, 2] 

GP_ATTITUDE[3, 2, 3] := GP_ATTITUDE[3, 2, 2] 

GP_ATTITUDE[3, 3, 3] := GP_ATTITUDE[3, 3, 2] 

GP_ATTITUDE[1, 1, 2] := GP_ATTITUDE[1, 1, 1] 

GP_ATTITUDE[1, 2, 2] := GP_ATTITDDE[1, 2, 1] 

GP_ATTITUDE[1, 3, 2] := GP_ATTITUDE[1, 3, 1] 

GP_ATTITUDE[2, 1, 2] := GP_ATTITUDE[2, 1, 1] 
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GP_ATTITUDE[2, 2, 2] := GP_ATTIT0DE[2, 2, 1] 

GP_ATTITUDE [ 2 , 3, 2] := GP_ATTITUDE[2, 3, 1] 

GP_ATTITUDE[3, 1, 2] := GP_ATTITUDE[3, 1, 1] 

GP_ATTITUDE [ 3 , 2, 2] := GP_ATTITUDE[3, 2, 1] 

GP_ATTITUDE[3, 3, 2] := GP_ATTITUDE[3, 3, 1] 

GP_ATTITUDE[1, 1, 1] := GP_ATTITUDE [1, 1, 0] 

GP_ATTITUDE [ 1 , 2, 1] := GP_ATTITUDE[1, 2, 0] 

GP_ATTITUDE[1, 3, 1] := GP_ATTITUDE [1, 3, 0] 

GP_ATTITUDE[2, 1, 1] := GP_ATTITUDE[2, 1, 0] 

GP_ATTITUDE[2, 2, 1] := GP_ATTITUDE[2, 2, 0] 

GP_ATTITUDE[2, 3, 1] := GP_ATTITUDE[2, 3, 0] 

GP_ATTITUDE[3, 1, 1] := GP_ATTITUDE[3, 1, 0] 

GP_ATTITUDE[3, 2, 1] := GP_ATTITUDE[3, 2, 0] 

GP_ATTITODE[3, 3, 1] := GP_ATTITUDE[3, 3, 0] 

( ★*•**********★★****★*★★*******★★★*★*★**★★*★*★*★**★*★**********★★★★★*★**** 

* 2) Compute the current vehicle altitude, velocities and attitude. 

* 

* For a more detailed description of this processing, see the section 

* 2.3 of the design introduction. 

************************************************************************J 

(*** simultanously compute the current vehicle attitude, velocities 

and altitude ***) 

(*** range check the following data elements ***) 

(************************************************************************ 

* In all other instances of range checking, the actual range checking 

* has been written out. Here, however, writing out all of the range 

* checking is prohibitively long. So, it should be sufficient to say, 

* range check the following data elements: 

* 

* element lower upper 

************************************************************************J 

GP_ATTITUDE[1, 1, 2] -1 1 

GP_ATTITUDE[1, 2, 2] -1 1 

GP_ATTITUDE[1, 3, 2] -1 1 

GP_ATTITUDE[2, 1, 2] -1 1 

GP_ATTITUDE [ 2 , 2, 2] -1 1 

GP_ATTITUDE[2, 3, 2] -1 1 

GP_ATTITUDE[3, 1, 2] -1 1 

GP_ATTITUDE[3, 2, 2] -1 1 

GP_ATTITUDE[3, 3, 2] -1 1 

GP_VELOCITY[l, 2] -100 100 

GP_VEL0CITY[2, 2] -100 100 

GP_VELOCITY[3, 2] -100 100 

GP_ALTITUDE[2] 0 2000 

(*** sensor data ***) 

G_ROTATION[l, 0] -1 1 
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G_R0TATI0N[2, 0] 

-1 

1 

G_ROTATION [ 3 , 0] 

-1 

1 

G_R0TATI0N[1, 1] 

-1 

1 

G_R0TATI0N[2, 1] 

-1 

1 

G_R0TATI0N[3, 1] 

-1 

1 

G_ROTATION[l, 2] 

-1 

1 

G_ROTATION [ 2 , 2] 

-1 

1 

G_R0TATI0N [ 3 , 2] 

-1 

1 

A_ACCELERATION [ 1 , 0] 

-20 

5 

A_ACCELERATION [ 2 , 0] 

-20 

5 

A_ACCELERATION [ 3 , 0] 

-20 

5 

A_ACCELERATION [ 1 , 1] 

-20 

5 

A_ACCELERATION [ 2 , 1] 

-20 

5 

A_ACCELERATION [ 3 , 1] 

-20 

5 

A_ACCELERATION [ 1 , 2] 

-20 

5 

A_ACCELERATION [ 2 , 2] 

-20 

5 

A_ACCELERATION [ 3 , 2] 

-20 

5 

TDLR_VELOCITY [ 1 , 0] 

-100 

100 

TDLR_VELOCITY [ 2 , 0] 

-100 

100 

TDLR_VELOCITY [ 3 , 0] 

-100 

100 

TDLR_VELOCITY [ 1 , 1] 

-100 

100 

TDLR_VELOCITY [ 2 , 1] 

-100 

100 

TDLR_VELOCITY [ 3 , 1] 

-100 

100 

TDLR_VELOCITY [ 1 , 2] 

-100 

100 

TDLR_VELOCITY [ 2 , 2] 

-100 

100 

TDLR_VELOCITY [ 3 , 2] 

-100 

100 

AR_ALTITUDE[0] 

0 

2000 

AR_ALTITUDE [1] 

0 

2000 

AR_ALTITUDE[2] 

0 

2000 


^************************************************************************ 

* A five step implementation of the RK method. The functions 

* deriv_att(), deriv_vel(), and deriv_alt() are described below. 

* 

* The interval begins at the current frame minus 2 frames. 

* 

* 1. Compute the first estimate of the incremental value for 

* GP_ATTITUDE, GP_VELOCITY, and GP_ALTITODE based upon the 

* rate of change at the beginning of the interval 

* (2 frames ago): 

* 

* estimate := rate_of_change * step_size 

************************************************************************j 

att_kl := der iv_att ( GP_ATTITUDE [ 1 , 1, 2], 2) * 2*DELTA_T 
vel_kl := der iv_vel ( GP_VELOCITY [ 1 , 2], 

GP_ATTITUDE[1, 1, 2], 2) * 2*DELTA_T 
alt_kl := deriv_alt(GP_ALTITUDE[2] , 

GP_VEL0CITY[1, 2], 

GP_ATTITUDE[1, 1, 2], 2) * 2*DELTA_T 

(************************************************************************ 

* 2. Compute the second estimate of the incremental value for 
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* GP_ATTITUDE, GP_VELOCITY, and GP_ALTITUDE based upon the 

* rate of change at the midpoint of the first estimate kl: 

************************************************************************ J 


att_k2 := der iv_att ( ( GP_ATTITUDE [ 1 , 1, 2] + att_kl/2), 1) * 2*DELTA_T 
vel_k2 := deriv_vel( (GP_VEL0CITY[1, 2] + vel_kl/2), 

(GP_ATTITUDE[1, 1, 2] + att_kl/2), 1) * 2*DELTA_T 
alt_k2 := der iv_alt ( ( GP_ALTITUDE [ 2 ] + alt_kl/2), 

(GP_VEL0CITY[1, 2] + vel_kl/2), 

(GP_ATTITUDE[1, 1, 2] + att_kl/2 ) , 1) * 2*DELTA_T 

^ ********** *************************** ************************************ 

* 3. Compute the third estimate of the incremental value for 

* GP_ATTITUDE, GP_VELOCITY, and GP_ALTITODE based upon the 

* rate of change at the midpoint of the second estimate k2: 
************************************************************************) 


att_k3 := deriv_att( (GP_ATTITUDE[1, 1, 2] + att_k2/2), 1) * 2*DELTA_T 
vel_k3 := deriv_vel( (GP_VEL0CITY[1, 2] + vel_k2/2), 

(GP_ATTIT0DE[1, 1, 2] + att_k2/2), 1) * 2*DELTA_T 
alt_k3 := deriv_alt( (GP_ALTIT0DE[2] + alt_k2/2), 

( GP_VELOCITY [ 1 , 2] + vel_k2/2), 

(GP_ATTIT0DE[1, 1, 2] + att_k2/2), 1) * 2*DELTA_T 

^************************************************************************ 

* 4. Compute the fourth estimate of the incremental value for 

* GP.ATTITUDE, GP_VELOCITY, and GP_ALTITUDE based upon the 

* the rate-of-change at the third estimate k3: 

************************************************************************J 


att_k4 := der iv_att ( ( GP_ATTITUDE [ 1 , 1, 2] + att_k3), 0) * 2*DELTA_T 
vel_k4 := deriv_vel( (GP_VELOCITY[l, 2] + vel_k3), 

(GP_ATTITUDE[1, 1, 2] + att_k3), 0) * 2*DELTA_T 
alt_k4 := der iv_alt ( ( GP_ALTITUDE [ 2 ] + alt_k3), 

(GP_VELOCITY[l, 2] + vel_k3), 

(GP_ATTITUDE[1, 1, 2] + att_k3), 0) * 2*DELTA_T 

^************************************************************************ 

* 5. Perform a weighted average of the four previously computed 

* estimates of the new value for GP_ATTITUDE, GP_VELOCITY, and 

* GP_ALTITUDE . 

* 

* Note, the syntax [*, x] and [*, *, x] represent the xth history of 

* the data element. 

************************************************************************) 

GP_ATTITUDE [ * , *, 0] := GP_ATTITUDE [ * , *, 2] + 

(l/6)(att_kl + 2*(att_k2 + att_k3) + att_k4) 

GP_VELOCITY [ * , 0] := GP_VELOCITY[*, 2] + 

( 1/6 ) ( vel_kl + 2*(vel_k2 + vel_k3) + vel_k4) 

GP_ALTITUDE[0] := GP_ALTITUDE[2] + 

( 1/6 ) ( alt_kl + 2*(alt_k2 + alt_k3) + alt_k4) 

(*** establish the "final" rotation matrix ***) 
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GP_ROTATION [ 1 , 1] := 0 

GP_R0TATI0N[1, 2] := G_R0TATI0N[3, 0] 

GP_ROTATION [ 1 , 3] := -G_ROTATION[2, 0] 

GP_ROTATION[2, 1] := -G_ROTATION [3 , 0] 

GP_ROTATION [ 2 , 2] := 0 

GP_ROTATION [ 2 , 3] := G_ROTATION[l, 0] 

GP_ROTATION [ 3 , 1] := G_ROTATION [ 2 , 0] 

GP_ROTATION [ 3 , 2] := -G_ROTATION[l, 0] 

GP_ROTATION [ 3 , 3] := 0 

^*************** , A , ******** , *‘***** , * , *******************************lHt********' 

* 3) Determine if the engines should be switched on or off. 

************************************************************************ J 

^★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★*************************** 

* At the beginning of the trajectory, the axial engines are "off” 

* and the roll engines are "on." During the course of the 

* trajectory the axial engines are "switched on." Further along 

* the course of the trajectory, the axial engines and the roll 

* engines are "switched off." These engine "switching" decisions 

* are made here. 

(*** range check the current altitude ****) 

if (GP_ALTITUDE[0] < 0) {1} 

display - error ( " %EXCEPTIONAL - CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 

"GP GP", FRAME_COUNTER , 

"GP_ALTITUDE" , GP_ALTITUDE[0] ) 

else if (GP_ALTITUDE[0] > 2000) [1} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED\ 

"GP GP", FRAME_COUNTER , 

"GP_ALTITUDE" , GP_ALTITDDE[0] ) 

end if {1} 

(*** range check the current x-axis vehicle velocity ****) 

if (GP_VELOCITY[l, 0] < -100) {1} 

display - error ( " %EXCEPTIONAL - CONDITION- GCS - LOWER_LIMIT_EXCEEDED " , 

"GP GP", FRAME_COUNTER , 

"GP_VELOCITY" , GP_VELOCITY [ 1 , 0]) 

else if (GP_VELOCITY[l, 0] > 100) {1] 

display-error ( " ^EXCEPTIONAL- CONDITION- GCS -UPPER_LIMIT_EXCEEDED” , 

"GP GP", FRAME_COUNTER, 

"GP_VELOCITY" , GP_VELOCITY [ 1 , 0]) 

end if { 1 } 

^ ★★★ ★★★ J 

if (AE_SWITCH = 0) then (* axial engines are "off" *) {1} 

if (RE_SWITCH = 1) then (* engines not prev. "off" *) {2) 

if (TD_SENSED = 0) then (* touch down "not sensed" *) {3} 

if (GP_ALTITUDE[0] <= ENGINES_ON_ALTITUDE) then {4} 
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AE_SWITCH := 1 (* switch axial engines "on" *) 

FRAME_ENGINES_IGNITED := FRAME_COUNTER 
end if {4} 

end if {3] 

end if {2} 

else (* axial engines are "on" *) {1} 

if (TDJ3ENSED = 1) then (* touch down "sensed" *) {2} 

AE_SWITCH := 0 (* switch axial engines "off”*) 

RE_SWITCH := 0 (* switch roll engines "off" *) 

else (* touch down "not sensed" *) {2] 

if (GP_ALTITUDE[0] <= DR0P_HEIGHT) then {3] 

temp := 2*GRAVITY*maximum(GP_ALTITUDE[0] , 0) 

if (temp < 0) then {4} 

display - error ( " ^EXCEPTIONAL - CONDITION- GCS - NEGATIVE_SQUARE_ROOT " 
"GP GP", FRAME_COUNTER, 
temp) 

end if {4} 

if ( sqrt( temp )+GP_VELOCITY[ 1,0] <= MAX_NORMAL_VELOCITY ) then {4] 
AE_SWITCH := 0 (* switch axial engines "off"*) 

RE_SWITCH := 0 (* switch roll engines "off" *) 

end if {4] 

end if [3] 

end if {2} 

end if {1} 


^************************************************************************ 

* 4) Compute the current velocity error. 

* 

* For a more detailed description of the interpolation and extrapolation 

* algorithms, see the section labeled ”” in the design overview. 


(*** compute the optimal velocity ***) 

(*** convert GP_ALTITUDE from meters to kilometers ***) 
cur_altitude := GP_ALTITUDE[0] / 1000 

do for i := 1 to 100 {1] 

if ( CONTOUR_ALTITUDE [ i ] = cur_altitude) then {2} 

(*** found an exact match in the table ***) 

optimal_velocity := CONTOUR_VELOCITY(i) 

i := 101 (* early do loop exit *) 

else if ( CONTOUR_ALTITUDE [ i ] > cur_altitude) then {2} 

if (i > 1) then (3) 

(*** interpolate between i-1 and i ***) 
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(*** check for potential divide by zero condition ***) 

if ( CONTOUR_ALTITUDE [ i ] = CONTOUR_ALTITUDE[i-l] ) then {4] 

display - error ( "%EXCEPTIONAL-CONDITION-GCS-DIVIDE_BY_ZERO" , 
"GP GP", FRAME_COUNTER) 

end if {4] 

(*** interpolation formula ***) 

optimal_velocity := C0NT0UR_VEL0CITY[i-l] + 

( (CONTOUR_VELOCITY[i] - CONTOUR_VELOCITY [i-1] ) / 

( CONTOUR_ALTITUDE [ i ] - CONTOUR_ALTITUDE [i-1] ) ) * 
(cur_altitude - CONTOUR_ALTITUDE[i-l] ) 

i := 101 (* early do loop exit *) 

else (* i = 1 and altitude < table entry *) [3] 

(*** Extrapolate for altitude < smallest value in table entries ***) 

(*** check for potential divide by zero condition ***) 

if ( CONTOUR_ALTITUDE [ 2 ] = CONTOUR_ALTITODE[l] ) then [4} 

display- error ( " % EXCEPTIONAL -CONDITION- GCS - DIVIDE_BY_ZERO " , 
"GP GP", FRAME_COUNTER ) 

end if {4} 

(*** Extrapolation formula ***) 

optimal_velocity := CONTOUR_VELOCITY[l] - 

( (CONTOUR_VELOCITY[2] - CONTOUR_VELOCITY[l] ) / 

( CONTOUR_ALT I TUDE [ 2 ] - CONTOUR_ALTITUDE [ 1 ] ) ) * 


( CONTOUR_ALTITUDE [ 1 ] - cur_altitude) 

i := 101 (* early do loop exit *) 

end if {3} 

else (* CONTOUR_ALTITUDE[i] < cur_altitude) *) {2} 

if ( (CONTOUR_ALTITUDE[i] = 0) OR (i = 100)) then {3} 

(*** Extrapolate for altitude > largest value in table entries ***) 

(*** note, i points to first (lowest) "0" entry in the table ***) 

(*** check for potential divide by zero condition ***) 

if ( CONTOUR_ALT ITODE [ i - 1 ] = CONTOUR_ALTITUDE[i-2] ) then {4} 


display-error ( "%EXCEPTIONAL-CONDITION-GCS-DIVIDE_BY_ZERO" , 
"GP GP", FRAME_COUNTER ) 

end if { 4 ] 

(*** Extrapolation formula ***) 

optimal_velocity := CONTOUR_VELOCITY[i-l] + 

((CONTOUR_VELOCITY[i-l] - CONTOUR_VELOCITY[i-2] ) / 
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( C0NT0UR_ALTITUDE [ i - 1 ] - C0NT0UR_ALTITUDE[i-2] ) ) * 
(cur_altitude - C0NT0UR_ALTITUDE[i-l] ) 

i := 101 (* early do loop exit *) 


end if {3} 

end if {2} 

end do { 1 } 

(*** convert optimal_velocity from km/sec to m/sec ***) 

optimal_velocity := optimal_velocity * 1000 

(*** compute the velocity error ***) 

VELOC I T Y_ERROR := GP_VELOCITY[l, 0] - optimal_velocity 


^************************************************************************ 

* 5) Determine if the predetermined velocity-altitude contour has 

* been crossed. 

************************************************************************^ 


(*** range check the VELOCITY_ERROR ****) 

if (VELOCITY_ERROR < -300) {1} 

display-error("%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 

"GP GP", FRAME_COUNTER, 

B VELOCI T Y_ERROR " , VELOCITY.ERROR) 


else if (VELOCITY_ERROR > 20) {1} 

display-error("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 

"GP GP", FRAME_COONTER, 

"VELOCITY_ERROR" , VELOCITY_ERROR) 

end if {1} 

if (GP_ALTITUDE[0] <= ENGINES_ON_ALTITUDE) then {1} 

if (CONTOUR_CROSSED = 0) then (* "contour not crossed" *) [2] 

if (VELOCITY_ERROR >= 0) then {3} 

CONTOUR_CROSSED := 1 (* set "contour crossed" *) 

end if {3} 

end if [2} 

end if {1} 


* 6) Determine the current guidance phase. 

************************************************************************ ) 


case GP_PHASE of 

(*** trans from 1 to 2 when the "engines on altitude" is reached ***) 

{ 1 } 
{ 1 } 


1: if (GP_ALTITUDE[0] <= ENGINES_ON_ALTITUDE) then 

GP_PHASE := 2 
end if 

end [of case 1) 
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(*** trans from 2 to 5 when touch down is sensed ***) 

2: if (TD_SENSED = 1) then (* "touch down sensed" *) {1) 

GP_PHASE := 5 

else {1} 

(*** trans from 2 to 3 when the engines are hot and the chute is released ***) 
if (AEJTEMP = 2) then (* a-engines are "hot" *) {2} 


if ( CHUTE_RELEASED = 1) then (* "chute released" *) {3] 
GP_PHASE := 3 

end if {3) 

end if (2} 

end if {1} 


end {of case 2} 

(*** trans from 3 to 5 when touch down is sensed ***) 

3: if (TD_SENSED = 1) then (* touch down "sensed" *) {1} 

GP_PHASE := 5 

else (* touch down "not sensed" *) {1} 

{*** trans from 3 to 5 when the TD sensor fails and altitude too low ***) 

(*** trans from 3 to 4 when the TD sensor healthy and altitude too low ***) 

if (GP_ALTITUDE[0] =< DROP_HEIGHT) then (* too low *) {2} 

if (TDS_STATUS = 1) then (* sensor "failed"*) {3} 

GP_PHASE := 5 

else (* sensor "healthy" *) {3} 

temp := 2*GRAVITY*maximum(GP_ALTITUDE[0] , 0) 


if (temp < 0) then {4} 

display-error ( ”%EXCEPTIONAL- CONDITION- GCS _ NEGATIVE_SQUARE_ROOT” , 
"GP GP", FRAME_COUNTER , 
temp) 

end if {4} 

if ( sqrt( temp )+GP_VELOCITY[ 1,0] <= 

MAX_NORMAL_VELOCITY) then {4} 

GP_PHASE := 4 

end if {4} 

end if [3} 

end if {2} 

end if {1} 


end {of case 3) 

(*** trans from 4 to 5 when touch down is sensed ***) 

4: if (TD_SENSED = 1) then (* touch down "sensed" *) {1} 

GP_PHASE := 5 
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else (* touch down "not sensed" *) {1} 

(*** trans from 4 to 5 when the TD sensor fails ***) 

if (TDS_STATUS = 1) then (* sensor "failed"*) 

GP_PHASE := 5 
end if 
end if 

end {of case 4) 

end of case statement 

^************************************************************************ 

* 7) Determine the appropriate axial engine control law parameter index. 

j 

(*** Note, the optimal_velocity is computed above during the computing of 
the current velocity error. ***) 


if (CL = 1) then {1} 

if (optimal_velocity = DR0P_SPEED) then {2} 

if (GP_VEL0CITY[1, 0] < DROP_SPEED) then {3} 

CL := 2 

TE_INTEGRAL := 0 

end if {3) 

end if {2} 

end if {1} 


return 


{ 2 } 

{ 2 } 

{ 1 } 


( ************************************************************************ 

* Title: deriv_att 

* Description: 

* Compute the derivative of the vehicle attitude. 

* 

* Usage: 

* rate-of -change := deriv_att( attitude, i] 

* 

* Arguments : 

* attitude input pointer to longword array [1.. 3, 1..3] 

* i input longword integer - time history index 

* 

* where 

* pv := G_R0TATI0N[1, i] 

* qv : = G_R0TATI0N[2, i] 

* rv := G_R0TATI0N [ 3 , i] 

* 

************************************************************************1 


1 

0 

rv 

-qv | 

deriv_att : = | 

-rv 

0 

pv | x attitude 

1 

qv 

-pv 

0 1 

return 
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^************************************************************************ 

* Title: deriv_vel 

* Description: 

* Compute the derivative of the vehicle velocity. 

* 

* Usage: 

* rate -of -change := deriv_vel( velocity, attitude, i) 

* 

* Arguments : 

* velocity input pointer to longword array [1.. 3] 

* attitude input pointer to longword array [1.. 3, 1..3] 

* i input longword integer - time history index 

*★★★★★*★****★★★******★★*★★★***★*********★**★★*★★★*★★★*★★★★★★★•*★★**★★+*** J 


- 


” 

1 0 

rv 

-qv | 

deriv_vel := | -rv 

0 

pv | x velocity + 

1 qv 

-pv 

0 1 


| GRAVITY * attitude [1,3] + ACCELERATION [1, i] | 

| GRAVITY * attitude [2, 3] + A_ACCELERATION [ 2 , i ] | + 

| GRAVITY * attitude [3, 3] + A_ACCELERATION [ 3 , i ] | 


| TDLR_VELOCITY[l,i] - velocity [1] | 
K_MATRIX [ i ] X | TDLR_VEL0CITY[2,i] - velocity [2] | 
| TDLR_VEL0CITY [ 3 , i ] - velocity [3] | 


where 

pv := G_R0TATI0N[1, i] 
qv := G_R0TATI0N[2, i] 
rv := G_R0TATI0N[3, i] 

(* note that "K_MATRIX[i] " represents the "i" history of the 3x3 matrix *) 
return 

(************************************************************************ 

* Title: deriv_alt 

* Description: 

* Compute the derivative of the vehicle altitude. 

* 

* Usage: 

* rate-of-change := deriv_att( attitude, i) 

* 

* Arguments : 

* altitude input longword real 

* velocity input pointer to longword array [1.. 3] 

* attitude input pointer to longword array[1..3, 1..3] 

* i input longword integer - time history index 

************************************************************************) 
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deriv_alt = 

| - attitude [1, 3] -attitude [2, 3] -attitude [3, 3] | x velocity + 
K_ALT[i] * (AR_ALTITUDE[i] - altitude) 

END P_SPEC 


Cadre Technologies, Inc. 


B-83 



11:33:07 10 Jul 95 


GCS_pluto_g22 P-Spec 2.3;2: CP 


page 1 


NAME: 

2.3;2 

TITLE: 

CP 

INPUT/OUTPUT: 

CP_EXT_IN : datajn 
CP_SO_IN : datajn 
CP_GSJN : datajn 
COMM_SYNC_PATTERN : datajn 
PACKET : data_out 
C_STATUS : data_out 

BODY: 


Bubbles 1.8, 2.3, 3.5 and the associated P-Specs represent a single 
process, CP as described in P-Spec 1.8. 
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3;9 

Control Law Processing Subframe 


*OUt* ENGINE DATA 
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PAT - Control Law Processing Subframe 


SUBFRAME_COUNTER 

) 

"GCS_SIM_RENDEZVOUS" 

"AECLP" 

"CROP" 

"RECLP" 

"CP" 


■ 




■■■■■■ 



1 

1 

2 

3 

2 
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NAME: 

3.1 ;4 

TITLE: 

GCS_SIM_RENDEZVOUS 

INPUT/OUTPUT: 

EXTERNAL : datajn 
GUIDANCE_STATE : datajn 
SENSOR_OUTPUT : datajn 
RUN_PARAMETERS : datajn 
GUIDANCE_STATE : data_out 
EXTERNAL : data_out 
SENSOR_OUTPUT : data_out 
RUN_PARAMETERS : data_out 
ENGINE_DATA: data_out 
PACKET: data_out 
CHUTE_RELEASED : data_out 

BODY: 

BEGIN P-Spec 

GCS_SIM_RENDEZVOUS provides the interface to the vehicle. This module is provided by 
the systems group. 

Bubbles 1.1, 2.1, 3.1 and the associated P-Specs represent a single process. 

END P-Spec 
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NAME: 

3.1 ;4 

TITLE: 

GCS_SIM_RENDEZVOUS 

INPUT/OUTPUT: 

EXTERNAL : datajn 
GUIDANCE_STATE : datajn 
SENSOR_OUTPUT : datajn 
RUN_PARAMETERS : datajn 
GUIDANCE_STATE : data_out 
EXTERNAL : data_out 
SENSOR_OUTPUT : data_out 
RUN_PARAMETERS : data_out 
ENGINE_DATA: data_out 
PACKET: data_out 
CHUTE_RELEASED : data_out 

BODY: 

BEGIN P-Spec 

GCS_SIM_RENDEZVOUS provides the interface to the vehicle. This module is provided by 
the systems group. 

Bubbles 1.1, 2.1, 3.1 and the associated P- Specs represent a single process. 


END P-Spec 
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NAME: 

3.2;40 

TITLE: 

AECLP 

INPUT/OUTPUT: 

AE_SWITCH :data_in 

AE_TEMP :data_in 

A_ACCELERATION :data_ln 

CHUTE_RELEASED :data_in 

CL :data_in 

CONTOUR_CROSSED :data_in 

DELTA_T :data_in 

ENGINES_ON_ALTITUDE :data_in 

FRAME_COUNTER :data_ln 

FRAME_ENGINES_IGNITED :data_in 

FULL_UP_TIME :data_in 

GA :data_in 

GAX :data_in 

GP1 :data_in 

GP2 :data_in 

GPY :data_in 

GP_ALTITUDE :data_in 

GP_ATTITUDE :data_ln 

GP_ROTATION :data_ln 

GP_VELOCITY :data_ln 

GQ :data_in 

GR :data_in 

GRAVITY :datajn 

GV :data_in 

GVE :data in 


page 1 
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GVEI :data_in 
GVI :data_in 
GW :data_in 
GWI :data_in 
INTERNAL_CMD: datajn 
OMEGA :data_in 
PEJNTEGRAL :data_in 
PE_MAX :data_in 
PE_MIN :data_in 
TE_DROP :data_in 
TEJNIT :data_in 
TEJNTEGRAL :data_in 
TEJJMIT :data_in 
TE_MAX :data_in 
TE_MIN : datajn 
VELOCITY_ERROR :datajn 
YEJNTEGRAL :datajn 
YE_MAX : datajn 
YE_MIN :datajn 
AE_CMD :data_out 
AE_STATUS :data_out 
AE_TEMP :data_out 
INTERNAL_CMD :data_out 
PEJNTEGRAL :data_out 
TEJNTEGRAL :data_out 
TE_LIMIT :data_out 
YE INTEGRAL :data out 
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BODY: 

BEGIN P_SPEC 

( ************************************************************************ 

* AECLP -- Axial Engine Control Law Processing 

★ 

* AECLP processing is responsible for: 

* 1) determining the current operational status of the axial engines, and 

* 2) generating the appropriate axial engine commands. 

************************************************************************J 


^************************************************************************* 

* 1) Determine the current operational status of the axial engines. 

★ 

* The operational status of the axial engines is always reported 

* as "Healthy" (value 0). 


AE_STATUS := 0 

^************************************************************************* 

* 2) Generate the appropriate axial engine commands. 

* 

* Determine if the axial engines are on. If the axial engines 

* are "off" (value 0) then the axial engine commands are "0". 

* Otherwise, further processing is required in order to determine 

* the appropriate axial engine commands. 

*************************************************************************J 

if (AE_SWITCH = 0) then (* axial engines are off *) {1} 


AE_CMD [ 1 ] : 

= 0 

AE_CMD [ 2 ] : 

= 0 

AE_CMD [ 3 ] : 

= 0 


else {1} 

(************************************************************************* 

* The axial engines are "on" so further processing is required. 

* 

* 2A) determine the axial engine temperature. 

************************************************************************* J 


(*** range check the current altitude ***) 

if (GP_ALTITUDE[0] < 0) then {2} 

display-error( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"GP_ALTITUTE" , GP_ALTITUDE [0] ) 

else if (GP_ALTITUDE[0] > 2000) then (2) 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER, 

"GP_ALTITUTE", GP_ALTITUDE[0] ) 

end if {2} 
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* The three possible engine temperature states are: "Cold" (value 0), 

* "Warming up" (value 1), and "Hot" (value 2). The current temperature 

* of the axial engines is stored in the data element AE_TEMP . 
************************************************************************* ) 

if (GP_ALTITUDE[0] <= ENGINES_ON_ALTITUDE) then {2} 

if (AE_TEMP = 0) then (* engines are "Cold" *) {3] 

if ( ( FRAME_COUNTER - FRAME_ENGINES_IGNITED) * DELTAJT < {4] 

FULL_UP_TIME) then 

AEJTEMP := 1 (* "Warming up" *) 

end if (4} 

else if ( AE_TEMP = 1) then (* engines are "Warming up" *) (3} 

if ( ( FRAME_COUNTER - FRAME_ENGINES_IGNITED) * DELTAJT >= (4} 

FULL_UP_TIME ) then 
AE_TEMP := 2 (* "Hot" *) 

end if {4} 

end if {3} 

end if {2} 

^************************************************************************* 

* 2B) Compute the pitch error limit. 

(*** range check the pitch error integral ***) 

if ( PE_INTEGRAL < -100) then (2) 

display-error ( " ^EXCEPTIONAL -CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER, 

"PE_INTEGRAL", PE_INTEGRAL) 

else if (PE_INTEGRAL > 100) then {2] 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIHIT_EXCEEDED", 
"AECLP AECLP", FRAME_CODNTER, 

" PE_I NTEGRAL " , PE_I NTEGRAL ) 

end if (2) 

(*** range check the x-axis roll rate ***) 

if (GP_VELOCITY[l, 0] < -100) then [2] 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"x-axis GP_VELOCITY", GP_VELOCITY[l, 0]) 

else if (GP_VELOCITY [1, 0] > 100) then (2} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"x-axis GP_VELOCITY", GP_VELOCITY[l, 0]) 
end if (2) 

(*** range check the z-axis roll rate ***) 
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if (GP_VEL0CITY[3, 0] < -100) then {2} 

display-error ("%EXCEPTIONAL-CONDITION-GCS-LOVffiR_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COONTER, 

"z-axis GP_VELOCITY\ GP_VELOCITY [ 3 , 0]) 

else if (GP_VELOCITY[3, 0] > 100) then {2} 

display - error ( ”%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED n , 
"AECLP AECLP", FRAME_COUNTER , 

"z-axis GP_VELOCITY" , GP_VELOCITY [ 3 , 0]) 

end if {2] 

(*** check for potential divide by zero condition ***) 

if ( GP_VELOCITY [ 1 , 0] = 0) then {2} 

display-error ( ”%EXCEPTIONAL-CONDITION-GCS-DIVIDE_BY_ZERO" , 

"AECLP AECLP", FRAME_COUNTER , 

"x-axis GP_VELOCITY" ) 

end if {2} 

(*** compute the current value for PE_INTEGRAL ***) 

PE_INTEGRAL := PE_INTEGRAL + 

(GP_VELOCITY[3, 0] / ABS(GP_VELOCITY[l, 0])) * DELTA_T 

where "ABS() B represents the absolute value operation 

(*** range check the pitch error integral (again) ***) 

if ( PE_INTEGRAL < -100) then {2} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

”PE_INTEGRAL", PE_INTEGRAL) 

else if (PE_INTEGRAL > 100) then (2} 

display-error("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER, 

"PE_INTEGRAL" , PE_INTEGRAL) 

end if {2] 

(*** range check the pitch rotational displacement ***) 

if (GP_ROTATION[3, 1] < -1) then {2} 

display-error( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"GP_ROTATION", GP_ROTATION [ 3 , 1]) 

else if (GP_ROTATION[3, 1] > 1) then {2} 

display-error("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"GP_ROTATION" , GP.ROTATION [ 3 , 1]) 

end if {2} 

(*** compute the pitch error limit ***) 

pitch_error_limit : = GQ [CL] * GP_ROTATION[3, 1] + 
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GW[CL] * (GP_VEL0CITY[3, 0] / ABS(GP_VELOCITY[l, 0])) + 

GWI [CL] * PE_INTEGRAL 

if (pitch_error_limit < PE_MIN[CL]) then {2} 

pitch_error_limit := PE_MIN[CL] 

else if (pitch_error_limit > PE_MAX[CL]) then {2] 

pitch_error_limit := PE_MAX[CL] 

end if {2} 


^************************************************************************* 

* 2C) Compute the yaw error limit. 

*************************************************************************J 


(*** range check the yaw error integral ***) 

if (YE_INTEGRAL < -100) then {2] 

display - error ( " %EXCEPTIONAL- CONDITION- GCS - LOWER_LIMIT_EXCEEDED * , 
"AECLP AECLP", FRAME.COUNTER, 

"YE_INTEGRAL\ YE_INTEGRAL) 

else if (YE.INTEGRAL > 100) then {2} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

" YE_INTEGRAL " , YE_INTEGRAL ) 

end if {2} 

(*** range check the y-axis roll rate ***) 

if (GP_VELOCITY[2, 0] < -100) then {2) 

display - error ( " %EXCEPTIONAL- CONDITION- GCS -LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"y-axis GP_VELOCITY" , GP_VELOCITY[2, 0]) 

else if (GP_VELOCITY[2, 0] > 100) then {2} 

display-error("%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER, 

"y-axis GP_VELOCITY", GP_VELOCITY[2, 0]) 

end if {2} 

(*** check for potential divide by zero condition ***) 

if (GP_VELOCITY[l, 0] = 0) then {2) 

display-error ("%EXCEPTIONAL-CONDITION-GCS-DIVIDE_BY_ZERO", 

"AECLP AECLP", FRAME_COUNTER , 

GP_VELOCITY[l, 0]) 

end if {2} 

(*** Compute the current value for YE_INTEGRAL ***) 

YE_INTEGRAL := YE_INTEGRAL + 

(GP_VELOCITY[2, 0] / ABS(GP_VELOCITY[l, 0])) * DELTAJT 

(*** range check the yaw error integral (again) ***) 
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if (YE_INTEGRAL < -100) then [2] 

display-error ( "%EXCEPTIONAL- CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"YE_INTEGRAL\ YE_INTEGRAL) 

else if (YE_INTEGRAL > 100) then (2) 

display-error ( " %EXCEPTIONAL -CONDITION- GCS-UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"YE_INTEGRAL" , YE_INTEGRAL) 

end if {2} 

(*** range check the yaw rotational displacement ***) 

if (GP_ROTATION[l, 2] < -1) then {2} 

display - error ( " % EXCEPTIONAL - CONDITION- GCS - LOWER_LIMIT_EXCEEDED " , 
"AECLP AECLP", FRAME_COUNTER, 

"GP_ROTATION" , GP_ROTATION [ 1 , 2]) 

else if (GP_ROTATION[l, 2] > 1) then {2} 

display- error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"GP_ROTATION" , GP_ROTATION [ 1 , 2]) 

end if {2] 

(*** compute the yaw error limit ***) 

yaw_error_limit := -GR [CL] * GP_ROTATION [ 1 , 2] + 

GV[CL] * (GP_VELOCITY[2, 0] / ABS(GP_VELOCITY[l, 0])) + 

GVI [CL] * YE_INTEGRAL 

if (yaw_error_limit < YE_MIN[CL] ) then {2} 

yaw_error_limit := YE_MIN[CL] 

else if (yaw_error_limit > YE_MAX[CL] ) then {2) 

yaw_error_limit := YE_MAX[CL] 

end if {2} 

( ************************************************************************* 

* 2D) Compute the thrust limiting error. 

************************************************************************* j 

if (CONTOUR_CROSSED = 1) (* "contour crossed" *) {2} 

(*** range check the thrust error integral ***) 

if (TE_INTEGRAL < -100) then [3} 

display-error("%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

" TE_INTEGRAL " , TE_INTEGRAL ) 

else if (TE_INTEGRAL > 100) then {3} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"TE_INTEGRAL", TE_INTEGRAL) 

end if { 3 ) 
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(*** range check the velocity error ***) 

if (VEL0CITY_ERR0R < -300) then {3} 

display - error (" mCEPTIONAL - CONDITION-GCS - LOWER_LIMIT_EXCEEDED ", 
"AECLP AECLP”, FRAME_COUNTER , 

" VELOCIT Y_ERROR ” , VELOCITY_ERROR) 

else if ( VELOC I T Y.ERROR > 20) then (3) 

display - error ( " %EXCEPTIONAL - CONDITION- GCS-UPPER_LIMIT_EXCEEDED” , 
"AECLP AECLP", FRAME_COUNTER , 

"VELOCITY_ERROR" , VELOCITY_ERROR) 

end if {3} 

(*** Compute the current value for TE_INTEGRAL ***) 

TE_INTEGRAL := TE_INTEGRAL + VELOCITY_ERROR * DELTA_T 
(*** range check the thrust error integral (again) ***) 

if (TE_INTEGRAL < -100) then {3} 

display-error ( " %EXCEPTIONAL - CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER, 

"TE_INTEGRAL" , TE_INTEGRAL) 

else if (TE_INTEGRAL > 100) then {3} 

display - error ( " ^EXCEPTIONAL -CONDITION-GCS -UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"TE_INTEGRAL" , TE_INTEGRAL) 

end if (3} 

(*** range check the attitude component ***) 

if (GP_ATTITUDE[1, 3, 0] < -1) then {3} 

display-error ( " %EXCEPTIONAL- CONDITION-GCS -LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"GP_ATTITUDE", GP_ATTITUDE[1, 3, 0]) 

else if (GP_ATTITUDE[1, 3, 0] > 1) then {3) 

display-error ( ”%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"GP_ATTITUDE", GP_ATTITUDE[1, 3, 0]) 

end if {3} 

(*** range check the x-axis acceleration ***) 

if (ACCELERATION [1, 0] < -20) then {3} 

display-error ( " %EXCEPTIONAL -CONDITION-GCS -LOWER_LIMIT_EXCEEDED” , 
"AECLP AECLP", FRAME_COUNTER , 

"X-axis ACCELERATION", ACCELERATION [1, 0]) 

else if ( A_ACCELERATION [ 1 , 0] > 5) then {3} 

display-error ( "^EXCEPTIONAL- CONDITION-GCS -UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"x-axis ACCELERATION", A_ACCELERATION [ 1 , 0]) 

end if ( 3 ) 
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(*** range check the thrust error limit ***) 

if (TE_LIMIT < -100) then {3] 

display-error ( " IEXCEPTIONAL- CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

"TE_LIMIT", TE_LIMIT) 

else if (TE_LIMIT > 100) then {3] 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

"TE_LIMIT", TE_LIMIT) 

end if {3] 

(************************************************************************ 

* Section "Algorithms not specificied in GCS Development 

* Specification" of the Design Overview contains a derivation of 

* the following equation used to compute TE_LIMIT. 

************************************************************************J 

let e := 2.718281828459045 { the number "e" ) 

TE_LIMIT : = (q / OMEGA) + 

(TE_LIMIT - (q / OMEGA)) * e A ( -OMEGA * DELTA_T ) 

where q := GA * (-GAX * ( A_ACCELERATION [ 1 , 0] + GRAVITY * 
GP_ATTITUDE[1, 3, 0]) + GVE * VELOCITY_ERROR + 

GVEI [CL] * TE_INTEGRAL) 

(*** range check the current value of for the thrust error limit ***) 

if (TE_LIMIT < -100) then (3} 

display-error ("%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED\ 
"AECLP AECLP", FRAME_COONTER, 

"TE_LIMIT", TE_LIMIT) 


else if (TE_LIMIT > 100) then {3} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

”TE_LIMIT", TE_LIMIT) 

end if { 3 ] 

if (TE_LIMIT < TE_MIN[CL] ) then {3) 

TE_LIMIT : = TE_MIN[CL] 

else if (TE_LIMIT > TE_MAX[CL] ) then {3} 

TE_LIMIT := TE_MAX[CL] 

end if { 3 } 

end if {2] 


* 2E) Compute the pitch, yaw and thrust errors. 
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(*** Note, to get here (AEJ3WITCH = 1) ***) 


if ( CHOTE_RELEAS ED = 1) then (* "Chute Released" *) 


if (C0NT0UR_CR0SSED = 0) then (* "contour not crossed" *) 


pitch_error 
yaw_error 
thrust error 


= pitch_limiting_error 
= yaw_limiting_error 
= TE DROP 


else 

pitch_error 
yaw_error 
thrust_error 
end if 


(* "contour crossed" *) 
pitch_limiting_error 
yaw_limiting_error 
TE_LIMIT 


else 

pitch_error 

yaw_error 

thrust_error 


(* "Chute Attached" *) 
GQ [CL] * GP_ROTATION [ 3 , 1] 

-GR[CL] * GP_ROTATION [ 1 , 2] 

TE_INIT 


end if 


{ 2 ] 

{3} 


{3} 


{3} 


{ 2 } 


* 2F) Compute the axial engine value settings. 

*************************************************************************J 

INTERNAL_CMD[1] := GP1 * pitch_error + thrust_error 

INTERNAL_CMD [ 2 ] := GP2 * pitch_error - GPY * yaw_error + thrust_error 

INTERNAL_CMD [ 3 ] := GP2 * pitch_error + GPY * yaw_error + thrust_error 

* 2G) Convert the axial engine value settings to engine commands. 


(*** range check the internal command ***) 

if ( INTERNAL_CMD [ 1 ] < -0.7) then {2} 

display-error ( " %EXCEPTIONAL- CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

" I NTERNAL_CMD [ 1 ] " , I NTERNAL_CMD [ 1 ] ) 

else if ( I NTERNAL_CMD [ 1 ] > 1.7) then (2) 

display- error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

" INTERNAL.CMD [ 1 ] " , INTERNAL_CMD [ 1 ] ) 

end if {2] 

if ( INTERNAL_CMD [ 2 ] < -0.7) then {2] 

display-error ( " %EXCEPTIONAL- CONDITION- GCS-LOWER_LIMIT_EXCEEDED” , 
"AECLP AECLP", FRAHE_COUNTER , 

" INTERNAL_CMD [ 2 ] " , INTERNAL_CMD [ 2 ] ) 

else if ( INTERNAL_CMD [ 2 ] >1.7) then (2) 

display-error( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED", 
"AECLP AECLP", FRAME_COUNTER , 

" INTERNAL_CMD [ 2 ] " , INTERNAL.CMD [ 2 ] ) 
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end if {2} 

if ( INTERNAL_CMD [ 3 ] < -0.7) then [2} 

display - error ( " ^EXCEPTIONAL- CONDITION- GCS - LOWER_LIMIT_EXCEEDED " , 
"AECLP AECLP", FRAME_COUNTER , 

" INTERNAL_CMD [ 3 ] " , INTERNAL_CMD [ 3 ] ) 

else if ( INTERNAL_CMD [ 3 ] >1.7) then {2) 

display - error ( ” %EXCEPTIONAL- CONDITION- GCS -UPPER_LIMIT_EXCEEDED" , 
"AECLP AECLP", FRAME_COUNTER , 

" I NTERNAL_CMD [ 3 ] " , I NTERNAL_CMD [ 3 ] ) 

end if (2) 

(*** first engine ***) 

if ( INTERNAL.CMD [1] < 0) then {2} 

AE_CMD [ 1 ] := 0 

else if ( INTERNAL_CMD [ 1 ] <= 1) then {2} 

AE_CMD [ 1 ] := TRUNC(127 * I NTERNAL_CMD [ 1 ] + 0.5) 

where TRUNC() represents the truncation operation 

else {2} 

AE_CMD [ 1 ] := 127 

end if {2} 

(*** second engine ***) 

if ( INTERNAL_CMD [ 2 ] < 0) then [2} 

AE_CMD [ 2 ] := 0 

else if ( INTERNAL_CMD [ 2 ] <= 1) then [2} 

AE_CMD [ 2 ] := TRUNC(127 * INTERNAL_CMD [ 2 ] + 0.5) 

else {2} 

AE_CMD [ 2 ] := 127 

end if {2} 

(*** third engine ***) 

if ( INTERNAL_CMD [ 3 ] < 0) then {2} 

AE_CMD [ 3 ] := 0 

else if ( INTERNAL_CMD [ 3 ] <= 1) then {2] 

AE_CMD [ 3 ] := TRUNC(127 * INTERNAL.CMD [ 3 ] +0.5) 

else {2) 

AE_CMD [ 3 ] := 127 

end if {2} 

end if {!] 

END P_SPEC 


Cadre Technologies, Inc. 


B-101 



B-102 


CRCP 



1 1 :34:41 1 0 Jul 95 GCS_pluto_g22 P-Spec 3.3;24: CROP 


page 1 


NAME: 

3.3;24 

TITLE: 

CROP 

INPUT/OUTPUT: 

AE_TEMP : datajn 
CHUTE_RELEASED :data_in 
CHUTE_RELEASED:data_out 

BODY: 

BEGIN P_SPEC 

^************************************************************************ 

* CRCP -- Chute Release Control Processing 

★ 

* CRCP processing is responsible for: 

* 1) Determining whether or not to release the parachute. 

* The parachute is to be released during the same frame in which the 

* axial engine temperature becomes "HOT" (2). Valid states for 

* CHUTE_RELEASED are "Chute Attached" (0) and "Chute Released" (1). 

* *★★★*****★*★★★*★★★*****★★*★★★*★★★*************★★**★★★★★**★★★★'*★•*•*★*★★★★ 'j 

(*** 1) Determine whether or not to release the parachute. ***) 


if (CHUTE.RELEASED = 0) then 

(* Chute Attached *) 

{1} 

if (AE_TEMP = 2) then 

(* engines are "HOT” *) 

{2] 

CHUTE_RELEASED := 1 

(* release the chute *) 


end if 


{2} 

end if 


{ 1 3 


END P_SPEC 
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NAME: 

3.4:23 

TITLE: 

RECLP 

INPUT/OUTPUT: 

DELTA_T : datajn 

G_ROTATION : datajn 

PI : datajn 

P2 : datajn 

P3 : datajn 

P4 : datajn 

RE_SWITCH : datajn 

THETA : datajn 

THETA1 : datajn 

THETA2 : datajn 

RE_CMD : data_out 

RE_STATUS : data_out 

THETA : data out 

BODY: 

BEGIN P_SPEC 

(************************************************************************* 

* RECLP -- Roll Engine Control Law Processing 

* 

* RECLP processing is responsible for: 

* 1) determining the current operational status of the roll engines, and 

* 2) generating the appropriate roll engine command. 

************************************************************************* j 

(************************************************************************* 

* 1) Determine the current operational status of the roll engines. 

* 

* The operational status of the roll engines is always reported 

* as "healthy" (value 0). 

************************************************************************* j 

RE_STATUS := 0 

(************************************************************************* 

* 2) Generate the appropriate roll engine command. 

* 
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* Determine if the roll engines are on. If the roll engines 

* are "switched off" (value 0) then the roll engine command is "1". 

* *★★*****★★****★★★**★**•*•★★***********★★****★**★**★**★★★*★★★★*★*★★******* + J 

if (RE_SWITCH = 0) then (* roll engines are switched off *) {1] 

RE_CMD := 1 (* off + CW *) 

else {1} 


(*** range check the x-axis vehicle rotation rate ***) 

if (G_R0TATI0N[1 ,0] < -1.0) then [2} 

display-error ( " ^EXCEPTIONAL- CONDITION- GCS-LOWER_LIMIT_EXCEEDED" , 
"RECLP RECLP", FRAME_COUNTER , 

"x-axis G_R0TATI0N" , G_R0TATI0N[1 ,0]) 

else if (G_R0TATI0N[1 ,0] > 1.0) then {2} 

display- error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED" , 
"RECLP RECLP", FRAME_COONTER , 

"x-axis G_ROTATION" , G_R0TATI0N[1 ,0]) 

end if {2} 

(*** range check the x-axis vehicle rotation displacement ***) 

let pi := 3.14159265358979 

if (THETA < (0 - pi)) then (2) 

display - error ( " %EXCEPTIONAL - CONDITION - GCS - LOWER_LIMIT_EXCEEDED " , 
"RECLP RECLP", FRAME_COUNTER , 

"THETA", THETA) 

else if (THETA > pi) then {2} 

display-error ( " ^EXCEPTIONAL -CONDITION- GCS -UPPER_LIMIT_EXCEEDED" , 
"RECLP RECLP", FRAME_COONTER , 

"THETA", THETA) 

end if [2} 


(************************************************************************* 

* The roll engine command consists of two components: an 

* intensity, and a direction. Taking into account the command data 

* encoding, the possible intensities are: Off (0), Minimum (2), 

* Intermediate (4), and Maximum (6), and the possible directions 

* are Counterclockwise (0) and Clockwise (1). 

* 

* Both roll engine command components are determined from the 

* current value of the vehicle's roll rate and rotational 

* displacement about the x-axis. 

* 

* Employing Euler's method for differential equations, compute the 

* current x-axis angular displacement, theta. 

a************************************************************************) 


THETA := THETA + G_ROTATION[l ,0] * DELTA_T 
(*** range check the theta again before use ***) 
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if (THETA < (0 - pi)) then (2) 

display- error ( "%EXCEPTIONAL-CONDITION-GCS-LOWER_LIMIT_EXCEEDED" , 
"RECLP RECLP", FRAME_COUNTER , 

"THETA", THETA) 

else if (THETA > pi) then [2} 

display-error ( "%EXCEPTIONAL-CONDITION-GCS-UPPER_LIMIT_EXCEEDED" , 
"RECLP RECLP", FRAME_COUNTER , 

"THETA", THETA) 

end if [2] 

^************************************************************************* 

* From figure 5.2 "Graph for Deriving Roll Engine Commands" of the 

* GCS development specifications, determine the appropriate roll 

* engine intensity and direction. 


(*** check case when theta = 0 ***) 
if (THETA = 0) then 


{ 2 } 


if (G_ROTATION[l ,0] > P4) then 
RE_CMD : = 6 + 1 

else if (G_ROTATION[l ,0] < -P4) then 
RE_CMD := 6 + 0 
else 

RE_CMD := 0 + 1 
end if 

(*** check first and fourth quadrants ***) 
else if (THETA > 0) then 


(* max + cw *) 
(* max + ccw *) 
(* off + cw *) 


(3) 

(3) 

{3} 

{3} 


{ 2 } 


if (THETA <= THETA1) then 


13} 


if (G_ROTATION[l ,0] > P2) then 
RE_CMD := 6 + 1 

else if (G_ROTATION[l ,0] > PI) then 
RE_CMD := 4 + 1 

else if (G_ROTATION[l ,0] >= -P4) then 
RE_CMD := 0 + 1 
else 

RE_CMD := 6 + 0 
end if 


(* max + cw *) 
(* inter + cw * 
(* off + cw *) 
(* max + ccw *) 


(4} 

{4} 

{4} 

[4} 

[4] 


else if (THETA <= THETA2 ) then 


{3] 


if (G_R0TATI0N[1 ,0] > P2) then 
RE_CMD := 6 + 1 

else if (G_ROTATION[l ,0] > PI) then 
RE_CMD := 4 + 1 

else if (G_R0TATI0N[1 ,0] >0.0) then 
RE_CMD := 2 + 1 

else if (G_R0TATI0N[1 ,0] >= -P4) then 
RE_CMD := 0 + 1 
else 


(* max + cw *) 
(* inter + cw * 
(* min + cw *) 
(* off + cw *) 


{4] 

{4} 

{4} 

{4} 

14 } 
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RE_CMD : = 6 + 0 (* max + ccw * 

end if 

else (* THETA > THETA2 *) 

if (G_R0TATI0N[1 ,0] > -P3) then 
RE_CMD := 6 + 1 

else if (G_ROTATION [1 ,0] >= -P4) then 
RE_CMD := 0 + 1 
else 

RE_CMD := 6 + 0 
end if 

end if 

(*** check second and third quadrants ***) 

else (* THETA < 0 *) 

if (THETA >= -THETA1) then 

if (G_ROTATION[l ,0] > p4) then 
RE_CMD := 6 + 1 

else if (G_ROTATION[l ,0] >= -PI) then 
RE_CMD := 0 + 1 

else if (G_ROTATION[l ,0] >= -P2) then 
RE_CMD := 4 + 0 
else 

RE_CMD =6+0 
end if 

else if (THETA >= -THETA2) then 

if (G_ROTATION[l ,0] > P4) then 
RE_CMD := 6 + 1 

else if (G_ROTATION[l ,0] >= 0.0) then 
RE_CMD =0+1 

else if (G_ROTATION[l ,0] >= -PI) then 
RE_CMD := 2 + 0 

else if (G_ROTATION[l ,0] >= -P2) then 
RE_CMD := 4 + 0 
else 

RE_CMD := 6 + 0 
end if 

else (* THETA < -THETA2 *) 

if (G_ROTATION[l ,0] > P4) then 

RE_CMD := 6 + 1 (* max + cw *) 

else if (G_ROTATION[l ,0] >= P3) then 

RE_CMD := 0 + 1 (* off + cw *) 

else 

RE_CMD =6+0 (* max + ccw * 

end if 

end if 


(* max + cw *) 
(* off + cw *) 
(* min + ccw * 
(* inter + ccw 
(* max + ccw * 


(* max + cw *) 
(* off + cw *) 
(* inter + ccw 
(* max + ccw *; 


(* max + cw *) 
(* off + cw *) 
(* max + ccw * 


page 4 

i 

{4} 

{3} 

14} 

{4} 

(4} 

I 

{4} 

{3} 

{ 2 ] 

{3} 

{4} 

{4} 

{4} 

*) 

{4] 

i 

{4} 

{3} 

{4} 

{4] 

{4} 

I 

{4} 

*) 

{4} 

{4} 

{3} 

{4} 

{4} 

{4} 

{4} 

{ 3 } 
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end if 
end if 
END P_SPEC 


{ 2 } 
{ 1 ] 
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NAME: 

3.5;2 

TITLE: 

CP 

INPUT/OUTPUT: 

COMM_SYNC_PATTERN : datajn 
CP_SO_IN : datajn 
CP_GSJN : datajn 
CP_EXTJN : datajn 
PACKET : data out 
C_STATUS : data_out 

BODY: 

Bubbles 1.8, 2.3, 3.5 and the associated P-Specs represent a single 
process, CP described in P-Spec 1.8. 
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A_ACCELERATION (data flow, cel) = 

*A_ACCELERATION* 


DESCRIPTION: vehicle accelerations 


USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


AECLP, ASP, CP, GP 
meters/sec A 2 
[-20, 5] 

array(1..3, 0..4) of real-8 
data 

SENSORJDUTPUT 

TBD 


A_BIAS (data flow, cel) = 

*A_BIAS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


characteristic bias in the accelerometer measurements. 
ASP 

meters/sec A 2 
[-30, 0] 

array (1. .3) of real-8 
data 

RUN_PARAMETERS 

N/A 


A_COUNTER (data flow, del) = 

*A_COUNTER* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


accelerating along the x ,y and z axes 

ASP 

none 

[0, (2 A 15) -1] 

array (1.. 3) of Integer- 2 

data 

EXTERNAL 

N/A 


A_GAIN_0 (data flow, cel) = 

*A_GAIN_0* 


DESCRIPTION: standard gain in the accelerations 

USED IN: ASP 

UNITS: meters/sec A 2 


Cadre Technologies, Inc. 


B-112 



14:05:37 10 Jul 95 


GCS_pluto_g22 Data Dictionary 


page 


2 


RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


[ 0 , 1 ] 

array(1..3) of Real-8 
data 

RUN_PARAMETERS 

N/A 


A_SCALE (data flow, del) = 

*A_SCALE* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


multiplicative constant used to determine limit on deviation accelerometer values 

ASP 

none 

[0, 3] 

Integer- 4 
data 

RUN_PAREMETERS 

N/A 


A_STATUS (data flow, del) = 

[ " 0 " 

I n i" 

] 

*A_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


flag indicating whether or not the accelerometers are working properly 

ASP, CP 

none 

[0: healthy, 1: unhealthy] 
array(1..3, 0..3) of Logical -1 
data 

GUIDANCE_STATE 

N/A 


AE CMD (data flow, del) = 

*AE_CMD* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


valve settings for the axial engines 
AECLP, CP 
none 
[0, 127] 

array(1..3) of Integer-2 
data 

EXTERNAL 

TBD 
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AE_STATUS (data flow, del) = 

[ " 0 " 

I "i" 

] 

*AE_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of axial engines 

AECLP, CP 

none 

[0:healthy, 1: failed] 

Logical-1 

data 

GUIDANCE_STATE 

N/A 


AE_SWITCH (data flow, del) = 

[ "0 n 
I "i" 

] 

*AE_SWITCH* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


flag indicating whether or not axial engines are turned on 

AECLP, GP 

none 

[ 0 : AXIAL_ENGINES_ARE_OFF , 1 : AXIAL_ENGINES_ARE_ON] 

Logical-1 

data 

GUIDANCE.STATE 

N/A 


AE TEMP (data flow, del) = 

[ " 0 " 

I "i" 

| " 2 " 

] 

*AE_TEMP* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 


temperature of axial engines when they are turned on 

AECLP, CP, CRCP, GP 

none 

[0:cold, 1 :warming_up, 2: hot] 

Integer-2 

data 


Cadre Technologies, Inc. 


B-114 



14:05:37 10 Jul 95 


GCS_pluto_g22 Data Dictionary 


page 4 


DATA STORE: GUIDANCE_STATE 

ACCURACY : N/A 


AECLP_EX_IN (data flow) = 

CHUTE_RELEASED 
+ FRAME_COUNTER 


AECLP_GS_IN (data flow) = 


AE_SWITCH 
+ AE_TEMP 

+ FRAME_ENGINES_IGNITED 
+ CONTOUR_CROSSED 
+ GP_ALTITUDE 
+ GP_ATTITUDE 
+ GP.ROTATION 
+ GP_VELOCITY 
+ INTERNAL_CMD 
+ PE_INTEGRAL 
+ TE_INTEGRAL 
+ TE_LIMIT 
+ VELOCITY_ERROR 
+ YE_INTEGRAL 
+ CL 


AECLP_GS_OUT (data flow) = 

AE_STATUS 
+ AE_TEMP 
+ INTERNAL_CMD 
+ PE_INTEGRAL 
+ TE_INTEGRAL 
+ TE_LIMIT 
+ YE_INTEGRAL 


AECLP_RP_IN (data flow) = 

ENGINES_ON_ALTITUDE 
+ DELTA_T 
+ FULL_UP_TIME 
+ GAX 
+ GP2 
+ GQ 

+ GRAVITY 
+ GVE 
+ GVI 
+ GWI 
+ PE_MIN 
+ TE_INIT 
+ TE_MIN 
+ YE_MIN 
+ GA 
+ GP1 
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+ GPY 
+ GR 
+ GV 
+ GVEI 
+ GW 
+ OMEGA 
+ PE_MAX 
+ TE_DROP 
+ TE_MAX 
+ YE_MAX 


ALPHA_MATRIX (data flow, cel) = 

*ALPHA_MATRIX* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


matrix of misalignment angles 

ASP 

none 

[ -PI, PI] where PI = 3.141592653589793 

array (1..3, 1..3) of Real-8 

data 

RUN_PARAMENTERS 

N/A 


AR_ALTITUDE (data flow, cel) = 

*AR_ALTITUDE* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


altimeter radar height above terrain 
ARSP, CP, GP 
meters 
[ 0 , 2000 ] 

array(0. .4) of Real-8 
data 

SENSOR_OUTPUT 

TBD 


AR_COUNTER (data flow, del) = 

*AR_COUNTER* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 


counter containing elapsed time since transmission of radar pulse 

ARSP 

cycles 

[-1, (2^15) -1] 

Integer-2 

data 
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DATA STORE: EXTERNAL 

ACCURACY : N/A 


AR_FREQUENCY (data flow) = 

*AR_FREQUENCY* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


increment frequency of AR_COUNTER 
ARSP 

cycles/sec 
[1, 2.45x10*9] 

Real-8 

data 

RUN_PARAMETERS 

N/A 


AR_STATUS (data flow, del) = 

[ " 0 " 

I "i" 

] 

*AR_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of the altimeter radars 

ARSP, CP 

none 

[0: healthy, 1: failed] 
array(0..4) of Logical-1 
data 

GUIDANCE_STATE 

N/A 


ARSP_GS_IN (data flow) = 

AR_STATUS 
+ K_ALT 


ARSP_GS_OUT (data flow) = 

AR_STATUS 
+ K_ALT 


ASP_RP_IN (data flow) = 

A_BIAS 
+ A_GAIN_0 
+ A_SCALE 
+ ALPHA.MATRIX 
+ G1 
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+ G2 


ASP_SO_IN (data flow) = 

A_ACCELERATION 
+ ATMOSPHERIC_TEMP 


ATMOSPHERIC_TEMP (data flow, cel) = 

*ATMOSPHERIC_TEMP* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


atmospheric temperature 
ASP, CP, GSP, TSP 
degrees C 
[-200, 25] 

Real-8 

data 

SENSOR_OUTPUT 

TBD 


C_STATUS (data flow, del) = 

[ " 0 " 

I "i" 

] 

*C_STATUS* 


DESCRIPTION: 

USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


flag indicating whether or not the communications processor is working 

properly 

CP 

none 

[0: healthy, 1: failed] 

Logical-1 

data 

GUIDANCE.STATE 

N/A 


CHUTE_RELEASED (data/control flow, del) = 

[ " 0 " 
l "i" 

] 

*CHUTE_RELEASED* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 


signal indicating parachute has been released 

AECLP, CP, CRCP, GP 

none 

[0 : chute_attached, 1 : chute_released] 

Logical-1 
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ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


data condition 

EXTERNAL 

N/A 


CL (data flow, del) = 

[ "i" 

| " 2 " 


*CL* 

- - DESCRIPTION : index which specifies which set of control law parameters to use USED IN : AECLP , GP UNITS 
RANGE : [ 1 : first , 2 : second 

] DATA TYPE : Integer- 2 ATTRIBUTE : data DATA STORE : GUIDANCE_STATE ACCURACY : N / A 


COMM_SYNC_PATTERN (data flow, pel) = 

*COMM_SYNC_PATTERN* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


sixteen bit synchronization pattern 

CP 

none 

[0xD9B2] * hexadecimal notation * 

Integer- 2 

data 

RUN_PARAMETERS 

N/A 


CONTOUR_ALTITUDE (data flow, cel) = 

* C0NT0UR_ALT I TUDE * 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


altitude in velocity-altitude contour 
GP 

kilometers 

[-. 01 , 2 ] 

array (1..100) of Real-8 
data 

RUN_PARAMETERS 

N/A 


CONTOUR_CROSSED (data flow, del) = 

[ " 0 " 

I "i" 

] 

*contour_crossed* 
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DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


indicates if the velocity-altitude contour has been sensed 

AECLP, CP, GP 

none 

[ 0 : contour_not_crossed, 1 : contour_crossed] 

logical-1 

data 

GUIDANCE_STATE 

N/A 


CONTOUR_VELOCITY (data flow, cel) = 

*CONTOUR_VELOCITY* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


velocity in velocity-altitude contour 
GP 

kilometers/sec 
[0, 0.5] 

array(l. .100) of Real-8 
data 

RUN_PARAMETERS 

N/A 


CP_EXT_IN (data flow) = 

AE_CMD 

+ CHUTE_RELEASED 
+ FRAME_COUNTER 
+ RE_CMD 

+ SUBFRAME_COUNTER 


CP_GS_IN (data flow) = 

A_STATUS 
+ AE_STATUS 
+ AE_TEMP 
+ AR_STATUS 
+ C_STATUS 
+ CONTOUR.CROSSED 
+ G_STATUS 
+ GP_ALTITUDE 
+ GP_ATTITUDE 
+ GP_PHASE 
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+ GP_R0TATI0N 
+ GP_VELOCITY 
+ K_ALT 
+ K_MATRIX 
+ PE_INTEGRAL 
+ RE_STATUS 
+ TDLR_STATE 
+ TDLR_STATUS 
+ TDS_STATUS 
+ TE_INTEGRAL 
+ TS_STAT0S 
+ VEL0CITY_ERR0R 
+ YE_INTEGRAL 


CP_SO_IN (data flow) = 

ar_altitude 

+ ATMOSPHERIC_TEMP 
+ A_ACCELERATION 
+ G_ROTATION 
+ TDLR_VELOCITY 
+ TD_SENSED 


DELTA_T (data flow, del) = 

*DELTA_T* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


time step duration 
AECLP, GP, RECLP, TDLRSP 
seconds 
[0.005, 0.20] 

Real-8 

data 

RUN_PARAMETERS 

N/A 


DROPJHEIGHT (data flow, del) = 

*DROP_HEIGHT* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


height from which vehicle should free-fall to surface 
GP 

meters 

[ 0 , 100 ] 

Real -8 
data 

RUN_PARAMETERS 

N/A. 
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DROP_SPEED (data flow, del) = 

*DROP_SPEED* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


optimal speed during constant velocity descent 
GP 

meters/sec 
[0, 4.0] 

Real -8 
data 

RUN_PARAMETERS 

N/A 


ENGINE_DATA (data flow) = 

AE_CMD 
+ RE_CMD 


ENGINES_ON_ALTITUDE (data flow, del) = 

*ENGINES_ON_ALTITUDE* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


altitude at which the axial engines are turned on; 
AECLP, GP 
meters 
[ 0 , 2000 ] 

Real-8 

data 

RUN_PARAMETERS 

N/A 


EXTERNAL (store) = 


Implementaion of the data elements in the data store EXTERNAL must be 
arranged in the order specified below. 
★ 


A_COUNTER 
+ AE_CMD 
+ AR_COUNTER 
+ CHUTE_RELEASED 
+ FRAME.COUNTER 
+ G_COUNTER 
+ PACKET 
+ RE_CMD 
+ SS_TEMP 
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+ SUBFRAME_COUNTER 
+ TD_COUNTER 
+ TDLR_COUNTER 
+ THERM0_TEMP 


FRAME_BEAM_UNLOCKED (data flow, del) = 

*FRAME_BEAM_UNLOCKED* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


variable containing the number of the frame during which the radar beam unlocked 

TDLRSP 

none 

[ 0 , ( 2 ^ 31 ) - 1 ] 
array(1..4) of Integer-4 
data 

GUIDANCE_STATE 

TBD 


FRAME_COUNTER (data flow) = 

*FRAME_COUNTER* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


counter containing the number of the present frame; 

AECLP, CP, GP, TDLRSP, ARSP 

none 

[1, (2 A 31) -1] 

Integer-4 

data 

EXTERNAL 

N/A 


FRAME_ENGINES_IGNITED (data flow, del) = 

*FRAME_ENGINES_IGNITED* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


variable containing the number of the frame during which the engines were ignited 

AECLP, GP 

none 

[0, (2 A 31) -1] 

Integer-4 

data 

GUIDANCE_STATE 

TBD 
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FULL_UP_TIME (data flow, del) = 

*FULL_UP_TIME* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


time for axial engines to reach optimum operational condition 
AECLP 
seconds 
[0, 60] 

Real-8 

data 

RUN_PARAMETERS 

N/A 


G1 (data flow, del) = 

*G1* 


- - DESCRIPTION : coefficent used to adjust A_GAIN USED IN : ASP UNITS : ( meters / sec A 2 ) / ( degree_C ) R 
] DATA TYPE : Real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


G2 (data flow, del) = 

*G2* 

- - DESCRIPTION : coefficent used to adjust A_GAIN USED IN : ASP UNITS : ( meters / sec A 2 ) / degree_C A 2 R 
] DATA TYPE : Real- 8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A . 


G3 (data flow, del) = 

*G3* 

- - DESCRIPTION : coefficent used to adjust G_GAIN USED IN : GSP UNITS : ( radians / sec ) / degree_C RANGE : 
] DATA TYPE : Real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


G4 (data flow, del) = 

*G4* 


- - DESCRIPTION : coefficient used to adjust G_GAIN USED IN : GSP UNITS : ( radians / sec ) / degree_C A 2 RAN 
] DATA TYPE : Real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


G_COUNTER (data flow, del) = 

*G_COUNTER* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 


gyroscope measurement of vehicle rotation rates; 

GSP 

none 

[- (2 A 14) -1, (2 A 14) -1] 
array (1..3) of Integer- 2 
data; 
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DATA STORE: EXTERNAL 

ACCURACY : N/A 


G_GAIN_0 (data flow, del) = 

*G_GAIN_0* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


standard gain in vehicle rotation rates as measured by the gyroscopes 
GSP 

radians/sec 

[- 1 , 1 ] 

array (1. .3) of Real-8 
data 

RUN_PARAMETERS 

N/A 


G_OFFSET (data flow, del) = 

*G_0FFSET* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


standard offset of the rotation raw values 
GSP 

radians/sec 
[-0.5, 0.5] 

array (1. .3) of Real- 8 
data 

RUN_PARAMETERS 

N/A 


G_ROTATION (data flow, cel) = 

*G_ROTATION* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


vehicle rotation rates 
CP, GSP, GP, RECLP 
radians/sec 
[- 1 . 0 , 1 . 0 ] 

array (1..3, 0..4) of Real-8 
data 

SENSOR_OUTPUT 

TBD 


G_STATUS (data flow, del) = 

[ " 0 " 
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I "i" 

] 

*G_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of the gyroscopes 

CP, GSP 

none 

[0: healthy, 1: failed] 

Logical-1 

data 

GUIDANCE_STATE 

N/A 


GA (data flow) = 

*GA* 


- - DESCRIPTION : gain USED IN : AECLP UNITS : sec / meter RANGE : [ 0 , 50 

] DATA TYPE : Real -8 ATTRIBUTE : data DATA 


RUN_PARAMETERS ACCURACY : N / A 


GAX (data flow) = 

*GAX* 


- - - DESCRIPTION : gain USED IN : AECLP UNITS : none RANGE : [ 0 , 5 

] DATA TYPE : Real -8 ATTRIBUTE : data DATA STORE 


RUN_PARAMETERS ACCURACY : N / A 


GP1 (data flow) = 

*GP1* 


- - - DESCRIPTION : gain USED IN : AECLP UNITS : none RANGE : 
RUN_PARAMETERS ACCURACY : N / A 


- , 5 

DATA TYPE : Real -8 ATTRIBUTE : data DATA STORE 


GP2 (data flow) = 

*GP2* 


- - - DESCRIPTION : gain USED IN : AECLP UNITS : none RANGE : 
RUN_PARAMETERS ACCURACY : N / A 


- , 5 

DATA TYPE : Real -8 ATTRIBUTE : data DATA STORE 


GP_ALTITUDE (data flow) = 

*GP_ALTITUDE* 


DESCRIPTION: altitude as seen by guidance processor 
USED IN: AECLP, CP, GP 
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UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


meters 

[ 0 , 2000 ] 

array (0. .4) of Real-8 
data 

GUIDANCE_STATE 

TBD 


GP_ATTITUDE (data flow) = 

*GP_ATTITUDE* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


direction cosine matrix 
AECLP, CP, GP 
none 
[- 1 , 1 ] 

array (1..3, 1..3, 0..4) Real- 8 
data 

GUIDANCE_STATE 

TBD 


GP_EX_IN (data flow) = 

CHUTE_RELEASED 
+ FRAME_COUNTER 


GP_GS_IN (data flow) = 

AE_SWITCH 
+ AE_TEMP 
+ CL 

+ CONTOUR_CROSSED 
+ GP_ALTITUDE 
+ GP_ATTITUDE 
+ GP_PHASE 
+ GP_VELOCITY 
+ K_ALT 
+ K_MATRIX 
+ RE_SWITCH 
+ TDS_STATUS 


GP_GS_OUT (data flow) = 

AE_SWITCH 
+ CONTOUR_CROSSED 
+ CL 

+ FRAME_ENGINES_IGNITED 
+ GP_ALTITUDE 
+ GP_ATTITUDE 
+ GP_PHASE 
+ GP_ROTATION 
+ GP_VELOCITY 
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+ RE_SWITCH 
+ TE_INTEGRAL 
+ VELOCITY_ERROR 


GP_PHASE (data/control flow, del) = 

[ "i" 

| " 2 " 

| "3" 

| "4” 

| "5" 

] 

*GP_PHASE* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


phase of operation as seen by guidance processor 
CP, GP 
none 
[1, 5] 

Integer-4 
data condition 
GUIDANCE_STATE 
TBD 


GP_ROTATION (data flow) = 

*GP_ROTATION* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


rotation rates as determined by the guidance processing functional unit 
AECLP, CP, GP 
radians/sec 
[- 1 . 0 , 1 . 0 ] 

array (1..3, 1..3) Real- 8 
data 

GUIDANCE_STATE 

TBD 


GP_RP_IN (data flow) = 

CONTOUR.ALTITUDE 
+ CONTOUR_VELOCITY 
+ DELTA_T 
+ DROP_HEIGHT 
+ ENGINES_ON_ALTITUDE 
+ GRAVITY 
+ DROP_SPEED 
+ MAX_NORMAL_VELOC I T Y 


GP_SO_IN (data flow) = 

A_ACCELERATION 
+ AR_ALTITUDE 
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+ G_R0TATI0N 
+ TD_SENSED 
+ TDLR_VELOCITY 


GP_VELOCITY (data flow) = 

*GP_VELOCITY* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


velocity as corrected by the guidance algorithm 
AECLP, CP, GP 
meters/sec 
[- 100 , 100 ] 

array (1..3, 0..4) of Real- 8 
data 

GUIDANCE_STATE 

TBD 


GPY (data flow) = 

*GPY* 


- - - DESCRIPTION : gain USED IN : AECLP UNITS : none RANGE : 
RUN_PARAMETERS ACCURACY : N / A 


- , 5 

DATA TYPE : Real- 8 ATTRIBUTE : data DATA STORE 


GQ (data flow) = 

*GQ* 


- - DESCRIPTION : gain USED IN : AECLP UNITS : seconds RANGE : [ - , 8 

] DATA TYPE : array ( 1 ..2 ) of Real- 8 ATTRIBU 

GR (data flow) = 

*GR* 

- - DESCRIPTION : gain USED IN : AECLP UNITS : seconds RANGE : [ - , 8 

] DATA TYPE : array ( 1 ..2 ) of Real-8 ATTRIBU 


GRAVITY (data flow) = 

♦GRAVITY* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 


gravity of planet 
AECLP, GP 
meters/sec A 2 
[0, 100] 

Real-8 

data 

RUN_PARAMETERS 
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ACCURACY : N/A 


GSP_RP_IN (data flow) = 

G3 

+ G4 

+ G_GAIN_0 
+ G_0FFSET 


GSP_SO_IN (data flow) = 

ATMOSPHERIC_TEMP 
+ G_ROTATION 

GUIDANCE_STATE (store) = 

* - - -------- - — 

Implementaion of the data elements in the data store GUIDANCE_STATE 
must be arranged in the order specified below. 


A_STATUS 
+ AE_STATUS 
+ AE_SWITCH 
+ AE_TEMP 
+ AR_STATUS 
+ C_STATUS 
+ CL 

+ C0NT0UR_CR0SSED 
+ FRAME_BEAM_UNLOCKED 
+ FRAME_ENGINES_IGNITED 
+ G_STATUS 
+ GP_ALTITUDE 
+ GP_ATTITUDE 
+ GP_PHASE 
+ GP_R0TATI0N 
+ GP_VEL0CITY 
+ INTERNAL_CMD 
+ K_ALT 
+ K_MATRIX 
+ PE_INTEGRAL 
+ RE_STATUS 
+ RE_SWITCH 
+ TDLR_STATE 
+ TDLR_STATUS 
+ TDS_STATUS 
+ TE_INTEGRAL 
+ TE_LIMIT 
+ THETA 
+ TS_STATUS 
+ VEL0CITY_ERR0R 
+ YE_INTEGRAL 


GV (data flow) = 
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*GV* 

- - DESCRIPTION : gain USED IN : AECLP UNITS : sec / meter RANGE : [ - , 8 

] DATA TYPE : array 


GVE (data flow) = 

*GVE* 


- - - DESCRIPTION : gain USED IN : AECLP UNITS : / second RANGE : [ 0 , 500 

] DATA TYPE : Real -8 


RUN_PARAMETERS ACCURACY : N / A 


GVEI (data flow) = 

*GVEI* 


- - - DESCRIPTION : gain USED IN : AECLP UNITS : / sec A 2 RANGE : [ - , 40 

] DATA TYPE : array 


GVI (data flow) = 

*GVI* 

- - - DESCRIPTION : gain USED IN : AECLP UNITS : / meter RANGE : [ - , 5 

] DATA TYPE : array ( 


GW (data flow) = 

*GW* 

- - DESCRIPTION : gain USED IN : AECLP UNITS : sec / meter RANGE : [ - , 8 

] DATA TYPE : array 


GWI (data flow) = 

*GWI* 

- - - DESCRIPTION : gain USED IN : AECLP UNITS : / meter RANGE : [ - , 5 

] DATA TYPE : array ( 

INTERNAL_CMD (data flow) = 

*INTERNAL_CMD* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


real vector containing the command to be sent to the axial engines 

AECLP 

none 

[-0.7, 1.7] 

array (1. .3) of Real- 8 
data 

GUIDANCE_STATE 

TBD 


( 1 . .2 ) of Real-8 ATT 


ATTRIBUTE : data DATA S 


( 1 . .2 ) of Real-8 ATT 


1 ..2 ) of Real- 8 ATTRI 


( 1 . .2 ) of Real-8 ATT 


1 ..2 ) of Real-8 ATTRI 
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K_ALT (data flow) = 

*K_ALT* 

- - - - DESCRIPTION : determines use of altimeter radar by guidance processor USED BY : ARSP , CP , GP UNITS : 
RANGE : [ 0 , 1 

] DATA TYPE : array ( 0 ..4 ) of integer-4 ATTRIBUTE : data DATA STORE : GUIDANCE_STATE ACCURACY : N / 


K_MATRIX (data flow) = 

*K_MATRIX* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


determines use of the doppler radar by guidance processor. 
CP, GP, TDLRSP 
none 
[ 0 , 1 ] 

array (1..3, 1..3, 0..4) integer- 4 
data 

GUIDANCE_STATE 

N/A 


Ml (data flow) = 

*M1* 


- - DESCRIPTION : lower measured temperature calibration point for solid state temperature sensor .USED IN : T 
none RANGE : [ 0 , ( 2 A 15 ) - 

] DATA TYPE : interger-2 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


M2 (data flow) = 

*M2* 


- - DESCRIPTION : upper measured temperature calibration point for solid state temperature sensor .USED IN : T 
none RANGE : [ 0 , ( 2 A 15 ) - 

] DATA TYPE : integer- 2 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A . 


M3 (data flow) = 

*M3* 


- - DESCRIPTION : lower measured temperature calibration point for thermocouple pair temperature sensor USED I 
UNITS : none RANGE : [ 0 , ( 2 A 15 ) - 

] DATA TYPE : integer- 2 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


M4 (data flow) = 

*M4* 

- - DESCRIPTION : upper measured temperature calibration point for thermocouple pair temperature sensor USED I 
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UNITS : none RANGE : [ 0 , ( 2 A 15 ) - 

] DATA TYPE : integer- 2 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


MAX_NORMAL_VELOCITY (data flow) = 

*MAX_NORMAL_VELOCITY* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


maximum vertical velocity for safe landing 
GP 

meters/sec 
[0, 3.35] 
real-8 
data 

RUN_PARAMETERS 

N/A 


OMEGA (data flow) = 

*OMEGA* 


- - - - DESCRIPTION : gain of angular velocity USED IN : AECLP UNITS : / second RANGE : [ - 0 , 50 
] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


PI (data flow) = 

*pi* 


- - DESCRIPTION : pulse rate boundary USED IN : RECLP UNITS : radians / sec RANGE : [ 0 , 0 .05 
] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN.PARAMETERS ACCURACY : N / A 


P2 (data flow) = 

*P2* 


- - DESCRIPTION : pulse rate boundary USED IN : RECLP UNITS : radians / sec RANGE : [ 0 , 0 .05 
] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


P3 (data flow) = 

*P3* 


- - DESCRIPTION : pulse rate boundary USED IN : RECLP UNITS : radians / sec RANGE : [ 0 , 0 .05 
] DATA TYPE : real- 8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


P4 (data flow) = 

*P4* 


- - DESCRIPTION : pulse rate boundary USED IN : RECLP UNITS : radians / sec RANGE : [ 0 , 0 .05 
] DATA TYPE : real- 8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 
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PACKET (data flow) = 

♦PACKET* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


packet of telemetry data 


CP 

N/A 

N/A 

array 

data 


(1. .256) of integer-2 


EXTERNAL 

N/A 


PEJNTEGRAL (data flow) = 

*PE_INTEGRAL* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


integral portion of pitch error equation 
AECLP, CP 
meters 
[- 100 , 100 ] 
real-8 
data 

GUIDANCE.STATE 

TBD 


PE_MAX (data flow) = 

*PE MAX* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


maximum pitch error tolerable 
AECLP 
none 
[ 0 , 1 ] 

array (1. .2) of real-8 
data 

RUN_PARAMETERS 

N/A 


PE_MIN (data flow) = 

*PE_MIN* 


DESCRIPTION: minimum pitch error tolerable 
USED IN: AECLP 
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UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


none 

[- 1 , 0 ] 

array (1. . 2) of real-8 
data 

RUN_PARAMETERS 

N/A 


RAW_SENSOR_DATA (data flow) = 

A_C0UNTER 
+ AR_COUNTER 
+ G_C0UNTER 
+ SS_TEMP 
+ TD_COUNTER 
+ TDLR.COUNTER 
+ THERMO_TEMP 


RE CMD (data flow) = 

[ "l" 

| " 2 " 

| n 3" 

| "4" 

| ”5" 

| " 6 " 

| "7" 

] 

*RE_CMD* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 


roll engine command 
CP, RECLP 
none 
[1, 7] 

1 off 


2 minimum, counterclockwise 

3 minimum, clockwise 

4 intermediate, counterclockwise 

5 intermediate, clockwise 

6 maximum, counterclockwise 

7 maximum, clockwise 

DATA TYPE: integer- 2 

ATTRIBUTE: data 

DATA STORE : EXTERNAL 

ACCURACY: TBD 


RE_STATUS (data flow) = 

[ " 0 " 

I "i" 

1 
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*RE_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of the roll engines 

CP, RECLP 

none 

[0:healthy, 1: failed] 

logical-1 

data 

GUIDANCE_STATE 

N/A 


RE_SWITCH (data flow) = 

[ " 0 " 

I "i" 

] 

*RE_SWITCH* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


flag indicating whether or not the roll engines are turned on 

GP, RECLP 

none 

[ 0 : roll_engines_are_of f , 1 : roll_engines_are_on ] 

logical-1 

data 

GUIDANCE.STATE 

N/A 


RECLP_GS_IN (data flow) = 


RE_SWITCH 
+ THETA 


RECLP_GS_OUT (data flow) = 


RE.STATUS 
+ THETA 


RECLP_RP_IN (data flow) = 

DELTA_T 
+ PI 
+ P2 
+ P3 
+ P4 

.+ THETAl 
+ THETA2 
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RUN_PARAMETERS (store) = 


Implementaion of the data elements in the data store RUN_PARAMETERS 
must be arranged in the order specified below. 


A_BIAS 
+ A_GAIN_0 
+ A_SCALE 
+ ALPHA_MATRIX 
+ AR.FREQUENCY 
+ COMM_SYNC_PATTERN 
+ C0NT0UR_ALTITDDE 
+ C0NT0UR_VEL0CITY 
+ DELTAJI 
+ DR0P_HEIGHT 
+ DROP_SPEED 
+ ENGINES_ON_ALTITUDE 
+ FULL_UP_TIME 
+ G1 
+ G2 
+ G3 
+ G4 

+ G_GAIN_0 
+ G_0FFSET 
+ GA 
+ GAX 
+ GP1 
+ GP2 
+ GPY 
+ GQ 
+ GR 

+ GRAVITY 
+ GV 
+ GVE 
+ GVE I 
+ GVI 
+ GW 
+ GWI 
+ Ml 
+ M2 
+ M3 
+ M4 

+ MAX_NORMAL_VELOC I T Y 
+ OMEGA 
+ PI 
+ P2 
+ P3 
+ P4 

+ PE_MAX 
+ PE_MIN 
+ T1 
+ T2 
+ T3 
+ T4 
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+ TDLR_ANGLES 
+ TDLR.GAIN 
+ TDLR_L0CK_TIME 
+ TDLRJ3FFSET 
+ TE.DROP 
+ TE_INIT 
+ TE_MAX 
+ TE_MIN 
+ THETA1 
+ THETA2 
+ YE_MAX 
+ YE_MIN 


SENSOR_OUTPUT (store) = 


Implementaion of the data elements in the data store SENS0R_0UTPUT 
must be arranged in the order specified below. 
* 


A_ACCELERATION 
+ AR_ALTITUDE 
+ ATMOSPHERIC_TEMP 
+ G_R0TATI0N 
+ TD_SENSED 
+ TDLR_VELOCITY 


SS_TEMP (data flow) = 

*SS_TEMP* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


solid state temperature data 

TSP 

none 

[0, (2^15) -1] 
integer- 2 
data 

EXTERNAL 

N/A 


SUBFRAME_COUNTER (control flow, del) = 

[ "l" 

| " 2 " 

| "3" 

] 

*SUBFRAME_COUNTER* 


DESCRIPTION: Counter containing the number of the present subframe. 
USED IN: CP 
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UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


none 

[1,3] 

Integer-2 

data 

EXTERNAL 

N/A 


T1 (data flow) = 

*T1* 


- - DESCRIPTION 
degrees C RANGE 


lower ambient temperature calibration point for solid state temperature sensor USED IN : TSP 
[ - 50 , 250 

] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


T2 (data flow) = 

*T2* 

- - DESCRIPTION : upper ambient temperature calibration point for solid state temperature sensor USED IN : TSP 
degrees C RANGE : [ - 50 , 250 

] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


T3 (data flow) = 

*T3* 

- - DESCRIPTION : lower amibent temperature calibration point for thermocouple pair temperature sensor USED IN 
UNITS : degrees C RANGE : [ - 0 , 50 

] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


T4 (data flow) = 

*T4* 

- - DESCRIPTION : upper ambient temperature calibration point for thermocouple pair temperature sensor USED IN 
UNITS : degrees C RANGE : [ - 0 , 50 

] DATA TYPE : real -8 ATTRIBUTE : data DATA STORE : RUN_PARAMETERS ACCURACY : N / A 


TD_COUNTER (data flow) = 

*TD_COUNTER* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


value returned by touch down sensor 

TDSP 

none 

[ < -2^15) , (2^15) -1] 

integer- 2 

data 

EXTERNAL 

N/A 
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TD SENSED (data flow) = 

[ " 0 " 

I "i" 

] 

*TD_SENSED* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


flag indicating whether or not touch down has been sensed 

CP, GP, TDSP 

none 

[0 : touch_down_not_sensed, l:touch_down_sensed] 

logical-1 

data 

SENSOR_OUTPUT 

N/A 


TDLR_ANGLES (data flow) = 

*TDLR_ANGLES* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


vector of doppler radar beam offset angles (i.e., alpha ,beta , gamma) 

TDLRSP 

radians 

[0, PI/2) where PI = 3.141592653589793 

array (1. . 3) of real-8 

data 

RUN.PARAMETERS 

N/A 


TDLR COUNTER (data flow) = 

*TDLR_COUNTER* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


value returned by doppler radar 

TDLRSP 

none 

[0, (2 A 15) -1] 

array (1..4) of integer- 2 
data 

EXTERNAL 

N/A 


TDLR_GAIN (data flow) = 

*TDLR_GAIN* 
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DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


gain in doppler radar beam 
TDLRSP 
meters/sec 
[- 1 . 1 ] 
real -8 
data 

RUN_PARAMETERS 

N/A 


TDLR_LOCK_TIME (data flow) = 

*TDLR_LOCK_TIME* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


locking time of doppler radar beam 
TDLRSP 
seconds 
[0, 60] 
real -8 
data 

RUN_PARAMETERS 

N/A 


TDLR_OFFSET (data flow) = 

*TDLR_OFFSET* 


DESCRIPTION: offset in doppler radar beam 


USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


TDLRSP 
meters/sec 
[- 100 , 0 ] 
real -8 
data 

RUN.PARAMETERS 

N/A 


TDLR_STATE (data flow) = 

[ " 0 " 

I "l" 

] 

*TDLR_STATE* 


DESCRIPTION: state of the touch down landing radar beams 
USED IN: CP, TDLRSP 
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UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


none 

[0 : beam_unlocked, l:beam_locked] 

array ( 1 . .4) logical-1 

data 

GUIDANCE_STATE 

N/A 


TDLR_STATUS (data flow) = 

[ " 0 " 

I "i" 

] 

*TDLR_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of the doppler radar 

CP, TDLRSP 

none 

[0: healthy, 1: failed] 
array (1..4) of logical-1 
data 

GUIDANCE_STATE 

N/A 


TDLR_VELOCITY (data flow) = 

*TDLR_VELOCITY* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


velocity as computed by the touch down landing radar 
CP, GP, TDLRSP 
meters/sec 
[- 100 , 100 ] 

array (1..3, 0..4) of real-8 
data 

SENSOR_OUTPUT 

TBD 


TDLRSP_EXT_IN (data flow) = 

FRAME_COUNTER 
+ TDLR.COUNTER 


TDLRSP_GS_IN (data flow) = 

FRAME_BEAM_UNLOCKED 
+ K_MATRIX 
+ TDLR_STATE 
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TDLRSP_GS_OUT (data flow) = 

FRAME_BEAM_UNLOCKED 
+ K.MATRIX ' 

+ TDLR_STATE 
+ TDLR_STATUS 


TDLRSP_RP_IN (data flow) = 

DELTA_T 
+ TDLR_ANGLES 
+ TDLR_GAIN 
+ TDLR_LOCK_TIME 
+ TDLR_OFFSET 


TDS_STATUS (data flow) = 

[ " 0 " 

I "i" 

] 

*TDS_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of the touch down sensor 

CP, GP, TDSP 

none 

[0: healthy, 1: failed] 

logical-1 

data 

GUIDANCE.STATE 

N/A 


TE_DROP (data flow) = 

*TE_DROP* 


DESCRIPTION: 

USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


the axial thrust error when axial engines are warm and the 
velocity altitude contour has not been intersected. 

AECLP 
none 
[- 2 , 2 ] 
real -8 
data 

RUN_PARAMETERS 

N/A 


TEJNIT (data flow) = 

*TE_INIT* 
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DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


the axial thrust error when the axial engines are cold 
AECLP 
none 
[- 2 , 2 ] 
real-8 
data 

RUN_PARAMETERS 

N/A 


TEJNTEGRAL (data flow) = 

*TE_INTEGRAL* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


integral portion of thrust error equation 
AECLP, CP, GP 
meters 
[- 100 , 100 ] 
real -8 
data 

GUIDANCE_STATE 

TBD 


TE_LIMIT (data flow) = 

*TE_LIMIT* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


limiting thrust error 

AECLP 

none 

[- 100 , 100 ] 
real- 8 
data 

GUIDANCE_STATE 

TBD 


TE_MAX (data flow) = 

*TE_MAX* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY: 


maximum thrust error tolerable 
AECLP 
none 
[- 2 , 2 ] 

array (1. .2) of real- 8 
data 

RUN_PARAMETERS 

N/A 
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TE_MIN (data flow) = 

*TE_MIN* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


minimum thrust error tolerable 
AECLP 
none 
[- 2 , 2 ] 

array (1. .2) of real-8 
data 

RUN_PARAMETERS 

N/A 


THERMO_TEMP (data flow) = 

*THERM0_TEMP* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


thermocouple pair temperature 

TSP 

none 

[0, (2 A 15) -1] 
integer- 2 
data 

EXTERNAL 

N/A 


THETA (data flow) = 

*THETA* 


- - - - DESCRIPTION : roll angle USED IN : RECLP UNITS : radians RANGE : [ - I , PI 

] where PI = 3 .141592653589793 DATA 

real -8 ATTRIBUTE : data DATA STORE : GUIDANCE_STATE ACCURACY : TBD 


THETA1 (data flow) = 

*THETAl* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


pulse angle boundary 

RECLP 

radians 

[0, 0.05] 

real-8 

data 

RUN_PARAMETERS 

N/A 
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THETA2 (data flow) = 

*THETA2* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


pulse angle boundary 

RECLP 

radians 

[0, 0.05] 

real- 8 

data 

RUN_PARAMETERS 

N/A 


TS_STATUS (data flow) = 

[ " 0 " 

I "i" 

] 

*TS_STATUS* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


status of the temperature sensors in solid state, then thermocouple pair order 

CP, TSP 

none 

[0: healthy, 1: failed] 
array (1..2) of logical-1 
data 

GUIDANCE.STATE 

N/A 


TSP_EXT_IN (data flow) = 

SS_TEMP 
+ THERMO_TEMP 


TSP_RP_IN (data flow) = 

Ml 
+ M2 
+ M3 
+ M4 
+ T1 
+ T2 
+ T3 
+ T4 


VELOCITY_ERROR (data flow) = 

*VELOCITY_ERROR* 
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DESCRIPTION: 

USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


distance from velocity-altitude contour (difference in velocities from actual 
to desired on contour) 

AECLP, CP, GP 
meters/sec 
[-300, 20] 
real-8 
data 

GUIDANCE.STATE 

TBD 


YE INTEGRAL (data flow) = 

*YE_INTEGRAL* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE : 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


integral portion of yaw error equation 
AECLP, CP 
meters 
[- 100 , 100 ] 
real-8 
data 

GUIDANCE_STATE 

TBD 


YE_MAX (data flow) = 

*YE_MAX* 


DESCRIPTION: 
USED IN: 
UNITS: 

RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


maximum yaw error tolerable 
AECLP 
none 
[- 1 , 1 ] 

array (1. .2) of real- 8 
data 

RUN_PARAMETERS 

N/A 


YE_MIN (data flow) = 

*YE_MIN* 


DESCRIPTION: minimum yaw error tolerable 
USED IN: AECLP 

UNITS: none 
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RANGE: 

DATA TYPE: 
ATTRIBUTE: 
DATA STORE: 
ACCURACY : 


[- 1 , 1 ] 

array (1. .2) of real- 8 
data 

RUN_PARAMETERS 

N/A 
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Appendix C: Source Code for the Pluto Implementation of the 
Guidance and Control Software 


Author: Philip Morris, Lockheed Martin Engineering and Sciences Coip. 


This document was produced as part of Guidance and Control Software (GCS) Project conducted at 
NASA Langley Research Center. Although some of the requirements for the Guidance and Control 
Software application were derived from the NASA Viking Mission to Mars, this document does not 
contain data from an actual NASA mission. 
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* Module: AECLP.FOR 

* Facility: Pluto 

* P-Spec: 3.2 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for AECLP. 

* 

* List of Routines: 

* subroutine AECLP 

* Title: AECLP 

* Facility: Pluto 

* Abstract: 

* 1) determine the current operational status of the axial engines. 

* 2) generate the appropriate axial engine commands. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

subroutine AECLP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutput.for' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

*** declare local variables *** 

real*8 q_over_omega 

real*8 pitcherror 

real*8 pitcherrorlimit 

real*8 yawerror 

real*8 yawerrorlimit 

real*8 thrusterror 

integer 515 4 i 
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* 1) Determine the current operational status of the axial engines. 

AESTATUS = K$ HEALTHY 

* 2) Generate the appropriate axial engine commands. 

* 

* Determine if the axial engines are on. If the axial engines 

* are "off' (value 0) then the axial engine commands are "0". 

* Otherwise, further processing is required in order to determine 

* the appropriate axial engine commands. 

if (AE SWITCH .EQ. K$AXIAL_ENGINES_ARE_OFF) then 
AE_CMD(1) = 0 
AE_CMD(2) = 0 
AE_CMD(3) = 0 
else 

* The axial engines are "on" so further processing is required. 

* 

* 2A) determine the axial engine temperature. 


*** range check the current altitude *** 

call RANGE_CHECK(GP_ALTITUDE(0), K$GP_ALT1TUDE$LB, 

& K$GP_ALT1TUDE$UB, 'AECLP', K$GP_ALT1TUDE$NAME) 

* The three possible engine temperature states are: "Cold" (value 0), 

* "Warming up" (value 1), and "Hot" (value 2). The current temperature 

* of the axial engines is stored in the data element AETEMP. 


if (GP ALTITUDE(O) .LE. ENG1NES ON ALT1TUDE) then 

if (AE TEMP .EQ. K$COLD) then 

if ((FRAME COUNTER - FRAME ENG1NES1GN1TED) * 
& DELTAT .LT. FULL UP T1ME) then 

AETEMP = K$WARM1NG_UP 
end if 

else if (AE TEMP .EQ. K$WARM1NG_UP) then 
if ((FRAME COUNTER - FRAME ENG1NES1GN1TED) * 
& DELTA T .GE. FULL UP T1ME) then 
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AETEMP = K$HOT 
end if 
end if 
end if 

* 2B) Compute the pitch error limit. 


*** range check the pitch error integral *** 

call RANGE_CHECK(PE_INTEGRAL, K$PE_INTEGRAL$LB, 

& K$PE_INTEGRAL$UB, 'AECLP', K$PE_INTEGRAL$NAME) 

*** range check the x-axis roll rate *** 

call RAN GE_CHECK(GP_VEL0C1T Y ( 1 , 0), K$GP_VELOCITY$LB, 

& K$GP_VELOCIT Y $UB , 'AECLP', K$GP_VELOCITY$NAME) 

*** range check the z-axis roll rate *** 

call RANGE_CHECK(GP_VELOCITY (3, 0), K$GP_VELOCITY$LB, 

& K$GP_VEL0C1TY$UB, 'AECLP', K$GP_VELOCITY$NAME) 

*** check for potential divide by zero condition *** 

call ZER0_CHECK(GP_VEL0C1TY ( 1 , 0), 'AECLP') 

*** compute the current value for PE1NTEGRAL *** 

PE1NTEGRAL = PE1NTEGRAL + 

& (GP VELOC1TY (3, 0) / ABS(GP_VEL0C1TY(1, 0))) * DELTA T 

*** range check the pitch error integral (again) *** 

call RAN GE_CHECK(PE_1NTEGRAL , K$PE_1NTEGRAL$LB, 

& K$PE_1NTEGRAL$UB, 'AECLP', K$PE_1NTEGRAL$NAME) 

*** range check the pitch rotational displacement *** 

call RAN GE_CHECK(GP_ROT AT 10N(3 , 1), K$GP_R0TAT10N$LB, 

& K$GP_R0TAT10N$UB, 'AECLP', K$GP_R0TAT10N$NAME) 

*** compute the pitch error limit *** 

pitch error limit = GQ(CL) * GP_R0TAT10N(3, 1) + 

& GW(CL) * (GP_VELOCITY(3, 0) / ABS(GP_VELOClTY(l, 0))) + 

& GWl(CL) * PE1NTEGRAL 

if (pitch error limit .LT. PE MIN(CL)) then 
pitcherrorlimit = PEMIN(CL) 
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else if (pitcherrorlimit .GT. PEMAX(CL)) then 
pitcherrorlimit = PEMAX(CL) 

end if 

* 2C) Compute the yaw error limit. 


*** range check the yaw error integral *** 

call RAN GE_CEIECK( Y EINTEGRAL , K$YE_INTEGRAL$LB, 

& K$YE_INTEGRAL$UB, 'AECLP', K$YE_1NTEGRAL$NAME) 

*** range check the y-axis roll rate *** 

call RANGE_CHECK(GP_VEL0C1TY (2, 0), K$GP_VEL0C1TY$LB, 

& K$GP_VEL0C1TY$UB, 'AECLP', K$GP_VEL0C1TY $N AME) 

*** check for potential divide by zero condition *** 

call ZERO_CHECK(GP_VELOCITY(l, 0), 'AECLP') 

*** Compute the current value for YEINTEGRAL *** 

YEINTEGRAL = YEINTEGRAL + 

& (GP VELOC1TY (2, 0) / ABS(GP_VEL0C1TY( 1 , 0))) * DELTA T 

*** range check the yaw error integral (again) *** 

call RAN GE_CEIECK( Y E INTEGRAL , K$YE_1NTEGRAL$LB, 

& K$YE_1NTEGRAL$UB, 'AECLP', K$YE_1NTEGRAL$NAME) 

*** range check the yaw rotational displacement *** 

call RAN GE_CEIECK(GP_ROT AT 10N( 1 , 2), K$GP_R0TAT10N$LB, 

& K$GP_ROTATION$UB, 'AECLP', K$GP_R0TAT10N$NAME) 

*** compute the yaw error limit *** 

yaw error limit = -GR(CL) * GP_R0TAT10N(1, 2) + 

& GV(CL) * (GP VELOC1TY (2, 0) / ABS(GP_VELOClTY( 1 , 0))) + 

& GVl(CL) * YE INTEGRAL 

if (yaw error limit .LT. YE MIN(CL)) then 
yawerrorlimit = YE_M1N(CL) 

else if (yaw error limit .GT. YE MAX(CL)) then 
yawerrorlimit = YEMAX(CL) 
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end if 


* 2D) Compute the thrust limiting error. 


if (CONTOURCROSSED .EQ. K$CONTOUR_CROSSED) then 

* range check the thrust error integral *** 

call RANGE_CHECK(TE INTEGRAL, K$TE_1NTEGRAL$LB, 

& K$TE_1NTEGRAL$UB, 'AECLP', K$TE_1NTEGRAL$NAME) 

* range check the velocity error *** 


call RANGE_CHECK(VELOCITY_ERROR, K$VELOClTY_ERROR$LB, 

& K$VELOCITY_ERROR$UB, AECLP', K$VELOCITY_ERROR$NAME) 

*** Compute the current value for TEJNTEGRAL *** 

TEJNTEGRAL = TEJNTEGRAL + VELOCITYERROR * DELTA T 

*** range check the thrust error integral (again) *** 

call RANGE_CHECK(TE_INTEGRAL, K$TE_1NTEGRAL$LB, 

& K$TE_INTEGRAL$UB, 'AECLP', K$TE_1NTEGRAL$NAME) 

*** range check the attitude component *** 


call RAN GE_CHECK(GP_ATTITUDE( 1 , 3, 0), K$GP_ATT1TUDE$LB, 
& K$GP_ATT1TUDE$UB, 'AECLP', K$GP_ATT1TUDE$NAME) 

*** range check the x-axis acceleration *** 


call RAN GE_CHECK(A_ACCELERATION( 1 , 0), 

& K$A_ACCELERATION$LB, 

& K$A_ACCELERAT10N$UB, 'AECLP', K$A_ACCELERAT10N$NAME) 

* range check the thrust error limit *** 


call RAN GE_CHECK(TE_LIMIT, K$TE_L1M1T$LB, 

& K$TE_L1M1T$UB, 'AECLP', K$TE_L1M1T$NAME) 

*** 

* vl Changes for AR#23. Item 8. Added check for zero. 

call ZERO_CHECK(OMEGA, 'AECLP') 

q_over_omega = (GA * (-GAX * (A_ACCELERAT10N( 1 ,0) + 
& GRAVITY * GP_ATTITUDE( 1,3,0)) + GVE * 

& VELOCITY ERROR + GVEl(CL) * TEJNTEGRAL)) / 

& OMEGA 
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* vl Changes for AR#23. End Change. 

TELIMIT = q_over_omega + 

& (TE LIMIT - q_over_omega) * EXP(-OMEGA * DELTA T) 

*** range check the current value of for the thrust error limit *** 

call RAN GE_CHECK(TE_LIMIT, K$TE_LIMIT$LB, 

& K$TE_LIMIT$UB, 'AECLP', K$TE_LIMIT$NAME) 

if (TE LIMIT .LT. TE MIN(CL)) then 
TE_LIMIT= TEMIN(CL) 

else if (TE LIMIT .GT. TEMAX(CL)) then 
TELIMIT = TEMAX(CL) 
end if 
end if 

* 2E) Compute the pitch, yaw and thrust errors. 


*** Note, to get here (AE SWITCH = K$ AXI AL EN GINE S ON) *** 

if (CHUTERELEASED .EQ. K$CHUTE_RELEASED) then 

if (CONTOUR CROSSED .EQ. K$CONTOUR_NOT_CROSSED) then 
pitcherror = pitcherrorlimit 
yaw_error = yaw_error_limit 
thrusterror = TEDROP 

else 

pitcherror = pitcherrorlimit 
yaw_error = yaw_error_limit 
thrusterror = TELIMIT 
end if 




else 


"Chute Attached" *** 


pitch error = GQ(CL) * GP_ROTATION(3, 1) 
yaw error = -GR(CL) * GP_ROTATION( 1 , 2) 
thrust error = TE IN IT 


end if 


* 2F) Compute the axial engine value settings. 
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INTERNALCMD(l) = GP1 * pitcherror + thrusterror 
INTERN AL_CMD(2) = GP2 * pitch error - 
& GPY * yaw error + thrust error 

INTERN AL_CMD(3) = GP2 * pitch error + 

& GPY * yaw error + thrust error 

* 2G) Convert the axial engine value settings to engine commands. 


*** range check the internal command *** 

call RAN GE_CHECK(INTERN AL_CMD( 1 ) , K$INTERNAL_CMD$LB, 

& K$INTERNAL_CMD$UB, 'AECLP', K$ INTERN AL_CMD$NAME) 

call RANGE_CHECK(INTERNAL_CMD(2), K$INTERNAL_CMD$LB, 

& K$INTERNAL_CMD$UB, 'AECLP', K$INTERNAL_CMD$NAME) 

call RAN GE_CHECK(INTERN AL_CMD(3 ) , K$INTERNAL_CMD$LB, 

& K$INTERNAL_CMD$UB, 'AECLP', K$INTERNAL_CMD$NAME) 

*** do the convertion for each engine *** 

do i = 1,3 

if (INTERN AL_CMD(i) .LT. 0) then 
AE_CMD(i) = 0 

*** 

* vl Changes for AR#23. Item 2. Added DO to 0.5 

else if (INTERN AL_CMD(i) .EE. 1) then 
AE_CMD(i) = INT(127 * INTERN AL_CMD(i) + 0.5D0) 

*** 

* vl Changes for AR#23. End Change. 

else 

AE_CMD(i) = 127 

end if 
end do 

end if 

return 

end 

***** of module AK C T P *®*^**®**®*^**®**®**®*^*^**®**®*^*^**®**®*^**®**®*^**®**®**®*^**®**®*^**®**^*®**®**®**®**®**®*^**®*^*^**®**®**®*^* 
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* Module: ARSP.FOR 

* Facility: Pluto 

* P-Spec: 1.2 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for ARSP. 

* 

* List of Routines: 

* subroutine ARSP 

* Title: ARSP 

* Facility: Pluto 

* Abstract: 

* 1 ) maintain the history of the altitude and altimeter sensor data 

* elements 

* 2) determine the operational status of the altimeter radar sensor 

* 3) Report the current altitude. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 10-JAN-1995 Philip Morris (PEM) 

subroutine ARSP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutputfor' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

* 1 ) Maintain the history of the altitude and the sensor status by 

* "rotating variables." 

AR_ALTITUDE(4) = AR_ALT1TUDE(3) 

AR_ALTITUDE(3) = AR_ALT1TUDE(2) 

AR_ALTITUDE(2) = AR_ALT1TUDE( 1 ) 

ARALTITUDE(l) = ARALTITUDE(O) 
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AR_STATUS(4) = AR_STATUS(3) 

AR_STATUS(3) = AR_STATUS(2) 

AR_STATUS(2) = ARSTATUS(l) 

ARSTATUS(l) = ARSTATUS(O) 

K_ALT(4) = K_ALT(3) 

K_ALT(3) = K_ALT(2) 

K_ALT(2) = K_ALT(1) 

K_ALT(1) = K_ALT(0) 

* 2) determine the operational status of the altimeter radar sensor. 

* 

* 3) There are three methods for determining the altitude. 

* 

* A) compute altitude from the sensor measurement. 

* 

* B) estimate altitude by fitting a third-order polynomial to the 

* altitude history data values. 

* 

* C) report the altitude as the most recently reported altitude. 


* If an echo has been received, then the lower order fifteen bits of 

* ARCOUNTER contain the raw sensor measurement, and the upper bit of 

* AR COUNTER will be clear (ie: 0). When an echo has not been received, 

* the AR COUNTER will contain 16 set bits (ie: OxFFFF). 

* 

* The data type of AR COUNTER is integer*2 and the valid value range 

* is specified as (-1, 32767). This implementation assumes that integer 

* values are represented by twos complement. Thus, when an echo has not 

* been recieved, the AR COUNTER will contain the value of -1 . Similarly, 

* when an echo has been received, AR COUNTER will contain a non-negative 

* value. 


if (AR COUNTER .NE. -1) then 
ARSTATUS(O) = K$HEALTHY 
K_ALT(0) = 1 

*** A) compute the altitude from the sensor measurement *** 

* vl Changes for PR#24. Item 8. Changed 3E08 to 3D08. 

* AR ALTITUDE(O) = (AR COUNTER * 3E08) / (2.0 * ARFREQUENCY) 
AR ALTITUDE(O) = (AR COUNTER * 3D08) / (2.0 * AR FREQUENCY) 

* vl Changes for PR#24. End Change. 
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else 


no echo received 
ARSTATUS(O) = K$F AILED 


*** if at least one of the history sensor status is "failed" *** 


if ((ARSTATUS(l) .EQ. K$FA1LED) .OR. 

& (AR_STATUS(2) .EQ. K$FA1LED) .OR. 

& (AR_STATUS(3) .EQ. K$FA1LED) .OR. 

& (AR_STATUS(4) .EQ. K$FA1LED)) then 

K_ALT(0) = 0 

*** C) return previously computed value *** 


*** range check the altitude **** 

call RAN GE_CHECK(AR_ALT1TUDE( 1 ),K$AR_ALTITUDE$LB, 

& K$AR_ALT1TUDE$UB,'ARSP', K$AR_ALTITUDE$NAME) 

*** the value stored in AR_ALTITUDE( 1 ) is aready 
*** stored in AR ALTITUDE(O)! 


else 

* 


all sensor status histories are "healthy" 


*** B) extrapolate the altitude *** 
K_ALT(0) = 1 

*** range check the altitude **** 


* vl Changes for PR#24. Extra. Changed ’ASP' to 'ARSP'. 

call RAN GE_CHECK(AR_ALT1TUDE( 1 ),K$AR_ALT1TUDE$LB, 

& K$AR_ALTITUDE$UB,'ARSP', K$AR_ALT1TUDE$NAME) 

call RANGE_CHECK(AR_ALTITUDE(2),K$AR_ALT1TUDE$LB, 

& K$AR_ALTITUDE$UB,'ARSP', K$AR_ALT1TUDE$NAME) 

call RAN GE_CHECK( AR_ALT1TUDE( 3 ) ,K$ AR_ ALTITUDESLB , 

& K$AR_ALTITUDE$UB,'ARSP', K$AR_ALT1TUDE$NAME) 

call RANGE_CHECK(AR_ALTITUDE(4),K$AR_ ALTITUDESLB, 

& K$AR_ALTITUDE$UB,'ARSP', K$AR_ALT1TUDE$NAME) 

AR ALTITUDE(O) = 4*AR_ALT1TUDE( 1 ) - 6 * AR ALT ITU DE(2) + 

& 4*AR_ALTITUDE(3) - AR_ALT1TUDE(4) 
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* vl Changes for PR#24. End Change. 

end if 
end if 


return 

end 


***** end of module arsp.for 
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* Module: ASP.FOR 

* Facility: Pluto 

* P-Spec: 1.3 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for ASP. 

* 

* List of Routines: 

* subroutine ASP 

* Title: ASP 

* Facility: Pluto 

* Abstract: 

* 1 ) maintaining the history of the accelerations and accelerometer 

* sensor statuses 

* 2) determining the operational status of the accelerometer sensors 

* 3) Reporting the current vehicle accelerations along each of the 

* vehicle's three axes. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 16-MAR- 1995 Philip Morris (PEM) 

subroutine ASP 
implicit none 

*** define local constants *** 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutput.for' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

*** declare local variables *** 

real*8 temp 

real*8 accel_m(3) 
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integer*4 i 

real*8 mean 

real*8 sd 

* 1 ) Maintain the history of the vehicle accelerations and 

* accelerometer sensor status by "rotating variables." 


A_ACCELERATION( 1 , 4) = AACCELERATION ( 1 , 3) 
A_ACCELERATION( 1 , 3) = A ACCELERATION ( 1 , 2) 
A ACCELERATION ( 1 , 2) = A_ACCELERATION(l , 1) 
A_ACCELERATION( 1 , 1) = A_ACCELERATION(l , 0) 

A_ACCELERATION(2, 4) = A_ACCELERATION(2, 3) 
A_ACCELERATION(2, 3) = A_ACCELERATION(2, 2) 
A_ACCELERATION(2, 2) = A_ACCELERATION(2, 1) 
A_ACCELERATION(2, 1) = A_ACCELERATION(2, 0) 

A_ACCELERATION(3, 4) = AACCELERAT ION(3 , 3) 
A_ACCELERATION(3, 3) = AACCELERAT ION (3 , 2) 
A_ACCELERATION(3, 2) = AACCELERAT ION (3 , 1) 
A_ACCELERATION(3, 1) = A_ACCELERATION(3, 0) 

A_STATUS(1, 3) = A_STATUS(1, 2) 

A_STATUS(1, 2) = A_STATUS(1, 1) 

A_STATUS(1, 1) = A_STATUS(1, 0) 

A_STATUS(2, 3) = A_STATUS(2, 2) 

A_STATUS(2, 2) = A_STATUS(2, 1) 

A_STATUS(2, 1) = A_STATUS(2, 0) 

A_STATUS(3, 3) = A_STATUS(3, 2) 

A_STATUS(3, 2) = A_STATUS(3, 1) 

A_STATUS(3, 1) = A_STATUS(3, 0) 

* 2) and 3), determine the operational status and the vehicle 

* accelerations for each axis. 


*** range check the atmospheric temperature **** 


call RANGE_CHECK(ATMOSPHERIC_TEMP,K$ATMOSPHERIC_TEMP$LB, 

& K$ATMOSPHERIC_TEMP$UB,'ASP', K$ ATMO SPHERIC T EMP$N AME) 

*** compute the preliminaiy value for the accelerations *** 


temp = (G1 * ATMOSPHERIC TEMP) + (G2 * ATMOSPHERIC_TEMP**2) 
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accel m(l) = A_BIAS(1)+ (AGAINO(l) + temp) * ACOUNTER(l) 
accel_m(2) = A_BIAS(2)+ (A_GAIN_0(2) + temp) * A_COUNTER(2) 
accel_m(3) = A_BIAS(3)+ (A_GAIN_0(3) + temp) * A_COUNTER(3) 

A_ACCELERATION( 1 , 0) = ALPHA_MATRIX(1, 1) * accel m(l) + 
& ALPHA_MATRIX( 1,2)* accel_m(2) + 

& ALPHA_MATRIX( 1,3)* accel_m(3) 

A_ACCELERAT10N(2, 0) = ALPHA_MATR1X(2, 1) * accel m(l) + 
& ALPHA_MATR1X(2, 2) * accel_m(2) + 

& ALPHA_MATR1X(2, 3) * accel_m(3) 

A_ACCELERAT10N(3, 0) = ALPHA_MATR1X(3, 1) * accel m(l) + 
& ALPHA _MATR1X( 3, 2) * accel_m(2) + 

& ALPHA_MATR1X(3, 3) * accel_m(3) 

* Determine whether or not the preliminary values for the 

* accelerations are reasonable. The preliminary value for an 

* acceleration is deemed reasonable: 1) if it differs from the mean 

* of the previous three measurements by not more than A SCALE 

* standard deviations; 2) when any of the three accelerometer 

* history statuses is "unhealthy" (value 1). If a preliminary 

* acceleration value is found to be reasonable, 

* then it is reported as the acceleration for it's axis. If a 

* preliminary value is not found to be reasonable, then the 

* mean of the previous three measurements is reported as the 

* acceleration for that axis. 

* 

* The current value for the sensor status is determined directly 

* from the reasonableness of the value of the preliminary 

* accleration. If the preliminary acceleration is reasonable, the 

* sensor status is deemed "healthy " (value 0). If the preliminary 

* acceleration is not reasonable, the sensor status is deemed 

* "unhealthy." 


do i=l,3 


* vl PR#27 Item 1. Adjust mean calculation. 

* if ((A_STATUS(i, 1) .EQ. K$ UNHEALTHY) .OR. 

* & (A_STATUS(i, 2) .EQ. K$UNHEALTHY) .OR. 

* & (A_STATUS(i, 3) .EQ. K$UNHEALTHY)) then 

* 

*** one or more history statuses are "unhealthy" *** 

* 

* A_STATUS(i, 0) = K$HEALTHY 

* 

* else 
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* all history status are "healthy" 

A_STATUS(i, 0) = K$HEALTHY 

if ((A_STATUS(i, 1) .EQ. K$HEALTHY) .AND. 

& (A_STATUS(i, 2) .EQ. K$HEALTHY) .AND. 

& (A_STATUS(i, 3) .EQ. K$HEALTHY)) then 

if ((A_ACCELERATION(i,l) .NE. A_ACCELERATION(i,2)) .OR. 

& ( AACCELERATION (i, 1 ) .NE. A_ACCELERAT10N(i,3))) then 

* vl PR#27 End Change. 


*** compute the mean of the previous three values *** 


*** range check the acceleration values **** 


call RAN GE_CHECK(A_ACCELERAT10N (i, 1 ),K$ A ACCELERATION $LB, 
& K$ A_AC C ELERAT ION $ UB , ' ASP' , K$ AACCELERAT ION $N AME ) 

call RANGE_CHECK(A_ACCELERAT10N(i, 2),K$A_ACCELERAT10N$LB, 
& K$A_ACCEEERATION$UB,'ASP', K$ AACCELERAT ION $N AME ) 

call RANGE_CHECK(A_ACCELERAT10N(i, 3 ),K$ A ACCELERATION $EB, 
& K$A_ACCELERAT10N$UB,'ASP', K$ AACCELERAT ION $N AME ) 

*** 

* vl PR#27 Item 2. Adjust Standard deviation calculation. 


*** compute the standard deviation *** 

mean = (A_ACCEEERATION(i, 1) + 

& A_ACCELERAT10N(i, 2) + 

& A_ACCELERAT10N(i, 3)) / 3.0D0 

temp = ((A ACCELERATION (i, 1 ) - mean)**2 + 
& (A_ACCELERAT10N(i,2) - mean)**2 + 

& (A_ACCELERAT10N(i,3) - mean)**2 ) 

& / 3.0D0 

sd = SQRT(temp) 

temp = ABS(mean - A ACCELERAT 10N(i, 0)) 
if (temp .GT. A SCALE * sd) then 
A_ACCELERATION(i, 0) = mean 
A_STATUS(i, 0) = K$UNHEALTHY 
end if 

end if ! close if block for A ACCELERATION 
end if ! close if block for A STATUS 
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end do 


* Note, numerical inaccuracies are inherent in the digital 

* representation of real numbers. Computing the variance can 

* potentially result in a small negative value, when the previous 

* accelerations have identical values. Therefore, the following 

* algorithm specifies a seperate case for computing the standard 

* deviation when the previous accelerations have identical values. 

if ((A_ACCELERATION(i,l) .EQ. A_ACCELERATION(i,2)) .AND. 
(A_ACCELERAT10N(i, 1 ) .EQ. A_ACCELERATION(i,3 ))) then 
sd = 0.0 
else 

temp = ((A_ACCELERATION(i, 1)**2 + 
A_ACCELERATION(i,2)**2 + 
A_ACCELERATION(i,3)**2) / 3.0) - mean**2 

call NEG_VALUE_CHECK(temp, 'ASP') 

sd = SQRT(temp) 

end if 

if (ABS(mean - A_ACCELERATION(i, 0)) .GT. 

A SCALE * sd) then 
A_ACCELERATION(i, 0) = mean 
A_STATUS(i, 0) = K$UNHEALTHY 
else 

A_STATUS(i, 0) = K$HEALTHY 
end if 

* end if 

* 

* end do 

* vl PR#27 End Change. 

return 

end 


* 

* 

* & 
* 

* 

* 

* & 

* & 
* 

* 

* 

* 

* 

* 

* 

* 

* & 
* 

* 

* 

* 

* 

* 


***** end of module asp. for 
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* Module: CLPSF.FOR 

* Facility: Pluto 

* P-Spec: 3.0 

* Abstract: 

* This module contains the entry for the control law processing 

* subframe. 

* 

* List of Routines: 

* subroutine CLPSF 

* Title: CLPSF 

* Facility: Pluto 

* Abstract: 

* This routine provides control of the Control Law Processing 

* SubFrame processing. 

* 

* Arguments: None 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 15-Feb-1995 Philip Morris (PEM) 

subroutine CLPSF 
implicit none 

*** execution begins here *** 

call GCSSIMRENDEZVOUS 

*** 

* vl Changes for AR#26. Item 1. Correct Spelling 
*** 

* call AELCP 
call AECLP 

*** 

* vl Changes for AR#26. Item 1. End Cahnge. 

*** 

call RECLP 
call CRCP 
call CP 

return 

end 

***** of module C/L'PSF FO.R- ******************************************* 
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* Module: CONSTANTS.FOR 

* Facility: Pluto 

* Abstract: 

* This module contains the constants used in Pluto. The constants 

* consist of values for enumerated types, upper and lower 

* bounds, and error reporting text. 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

* v2 10-Jan-1995 Philip Morris (PEM) 


*** define constant values (for enumerated types) 




*** AE TEMP values *** 


* vl Changes for AR#23. Item 4. Changed logical* 1 to integer*2 

integer*2 K$COLD 

parameter (K$COLD = 0) 

integer*2 K$WARM1NG_UP 
parameter (K$WARM1NG_UP = 1) 

integer*2 K$HOT 

parameter (K$FIOT = 2) 


* vl Changes for AR#23. End Change. 

*** AES WITCH values *** 

logical* 1 K$AX1AL_EN G1NESAREOFF 
parameter (K$ AX1AL EN GIN E S_ARE_OFF= 0) 

logical* 1 K$AX1AL_EN G1NESAREON 
parameter (K$AX1AL_EN G1NES ARE ON = 1) 

*** CHUTE RELEASED values *** 

logical* 1 K$CHUTE_ATT ACHED 
parameter (K$CHUTE_ATTACHED =0) 

logical* 1 K$CHUTE_RELEASED 
parameter (K$CHUTE_RELEASED = 1) 

*** CL values *** 
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integer* 2 K$FIRST 
parameter (K$FIRST =1) 

integer*2 K$SECOND 
parameter (K$SECOND = 2) 

CONTOURCROSSED values *** 

logical* 1 K$CONTOUR_NOT_CROSSED 
parameter (K$CONTOUR_NOT_CROSSED = 0) 

logical* 1 K$CONTOUR_CROSSED 
parameter (K$CONTOUR_CROSSED = 1) 

RE CMD values *** 

integer*2 K$CCW 

parameter (K$CCW = 0) 

integer*2 K$CW 
parameter (K$CW =1) 

integer*2 K$OFF 

parameter (K$OFF = 0) 

integer*2 K$M1N1MUM 
parameter (K$M1N1MUM = 2) 

integer*2 K$1NTERMED1ATE 
parameter (K$1NTERMED1ATE =4) 

integer*2 K$MAX1MUM 
parameter (K$MAX1MUM =6) 

RE SWITCH values *** 

logical* 1 K$ROLL_EN GIN E S_ AREOFF 
parameter (K$ROLL_EN G1NES ARE OF F = 0) 

logical* 1 K$ROLL_EN GIN E S_ AREON 
parameter (K$ROLL_EN GIN E S ARE ON = 1) 

Sensor statuses *** 

logical* 1 KSHEALTHY 
parameter (KSHEALTHY = 0) 

logical* 1 K$ UNHEALTHY 
parameter (KSUNHEALTHY = 1) 
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logical* 1 K$FA1LED 
parameter (K$FA1LED = 1) 


*** TD SENSED values *** 

logical* 1 K$TOUCH_DO WNNOTSEN SED 
parameter (K$TOUCH_DOWN_NOT_SENSED = 0) 

logical* 1 K$TOUCH_DOWN_SENSED 
parameter (K$TOUCH_DOWN_SENSED = 1) 

*** TDLRSTATE values *** 

logical* 1 K$BEAM_UNLOCKED 
parameter (K$BEAM_UNLOCKED= 0) 

logical* 1 K$BEAM LOCKED 
parameter (K$BEAM_LOCKED = 1) 

*** Rsn^c checking constants *®**®*^*^**^*®*^*^**®**®*^**^*®*^**®*^*^*^**^*®*^*^**®**®*^*^**®**®*^**®**®*^*^**®**^^* 

*** upper and lower bounds *** 

* vl Changes for AR#23. Item 3. Added DO to some reals. 

real*8 K$ AACCELERATION $LB 

parameter (K$ A ACCELERATION $LB = -20.0) 

real*8 K$ AACCELERATION $UB 

parameter (K$ A ACCELERATION $UB = 5.0) 

real*8 K$AR_ALTITUDE$LB 

parameter (K$AR_ALTITUDE$LB = 0.0) 

real*8 K$AR_ALTITUDE$UB 

parameter (K$AR_ALTITUDE$UB =2000.0) 

real*8 K$ATMOSPHERIC_TEMP$LB 

parameter (K$ATMOSPHERIC_TEMP$LB =-200.0) 

real*8 K$ATMOSPHERIC_TEMP$UB 

parameter (K$ATMOSPHERIC_TEMP$UB = 25.0) 

real*8 K$G_ROTATION$LB 

parameter (K$G_ROTATION$LB = -1.0) 

real*8 K$G_ROTATION$UB 

parameter (K$G_ROTATION$UB= 1.0) 

real*8 K$GP_ALTITUDE$LB 
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parameter (K$GP_ALTITUDE$LB = 0.0) 

real*8 K$GP_ALTITUDE$UB 

parameter (K$GP_ALTITUDE$UB =2000.0) 

real*8 K$GP_ATTITUDE$LB 

parameter (K$GP_ATTITUDE$LB = -L0) 

real*8 K$GP_ATTITUDE$UB 

parameter (K$GP_ATTITUDE$UB = LO) 

real*8 K$GP_ROTATION$LB 

parameter (K$GP_ROT AT ION $LB = -LO) 

real*8 K$GP_ROTATION$UB 

parameter (K$GP_ROTATION$UB = 1.0) 

real*8 K$GP_VEL0C1TY$LB 

parameter (K$GP_VEL0C1TY$LB =-100.0) 

real*8 K$GP_VELOCITY$UB 

parameter (K$GP_VEL0C1TY$UB = 100.0) 

real*8 K$1NTERN AL_CMD$LB 

parameter (K$1NTERNAL_CMD$LB = -0.7D0) 

real*8 K$1NTERNAL_CMD$UB 

parameter (K$INTERNAL_CMD$UB = 1.7D0) 

real*8 K$PE_INTEGRAL$LB 

parameter (K$PE_1NTEGRAL$LB =-100.0) 

real*8 K$PE_1NTEGRAL$UB 

parameter (K$PE_1NTEGRAL$UB = 100.0) 

real*8 K$TDLR_VEL0C1TY$LB 

parameter (K$TDLR_VELOCIT Y $LB =-100.0) 

real*8 K$TDLR_VEL0C1TY$UB 

parameter (K$TDLR_VELOCIT Y $UB = 100.0) 

real*8 K$TE_1NTEGRAL$LB 

parameter (K$TE_1NTEGRAL$LB =-100.0) 

real*8 K$TE_1NTEGRAL$UB 

parameter (K$TE_1NTEGRAL$UB = 100.0) 

real*8 K$TE_L1M1T$LB 

parameter (K$TE_L1M1T$LB =-100.0) 

real*8 K$TE_L1M1T$UB 
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parameter (K$TE_LIMIT$UB 


100 . 0 ) 


* v2 Changes for AR#24. Item 5. Changed signs. 

real*8 K$THETA$UB 

parameter (K$THETA$UB =3.141592653589793) 

real*8 K$THETA$LB 

parameter (K$THETA$LB =-3.141592653589793) 

* real* 8 K$THETA$UB 

* parameter (K$TE1ET A$UB =-3.141592653589793) 

* 

* real* 8 K$THETA$LB 

* parameter (K$TE1ET A$LB = 3.141592653589793) 

*** 

* v2 Changes for AR#24. End Change. 


real*8 K$VELOCITY_ERROR$LB 

parameter (K$VELOCITY_ERROR$LB =-300.0) 

real*8 K$VEL0C1TY_ERR0R$UB 

parameter (K$VELOCITY_ERROR$UB = 20.0) 

real*8 K$ Y E_1N TEGRAL SLB 

parameter (K$YE_1NTEGRAL$LB =-100.0) 

real*8 K$YE_1NTEGRAL$UB 

parameter (K$YE_1NTEGRAL$UB = 100.0) 


* vl Changes for AR#23. End Change. 


*** define constants for data element names used in error messages ****** 

character*^) K$ AACCELERATION $NAME 

parameter (K$ A ACCELERATION $NAME = 'A ACCELERATION') 

character*)*) K$AR_ALTITUDE$NAME 

parameter (K$AR_ALTITUDE$NAME = 'AR_ ALTITUDE') 

character*)*) K$ATMOSPHERIC_TEMP$NAME 

parameter (K$ATMOSPHERIC_TEMP$NAME= 'ATMOSPHERIC TEMP') 

character*)*) K$G_ROTATION$NAME 

parameter (K$G_ROTATION$NAME = 'G ROTATION') 

character*)*) K$GP_ALTITUDE$NAME 

parameter (K$GP_ALTITUDE$NAME = 'GP ALTITUDE') 


C-24 



character 5 ^*) K$GP_ATTITUDE$NAME 

parameter (K$GP_ATTITUDE$NAME = 'GP ATTITUDE') 

character*(*) K$GP_ROTATION$NAME 

parameter (K$GP_ROTATION$NAME = 'GP ROTATION') 

character*(*) K$GP_VELOCITY$NAME 

parameter (K$GP_VELOCITY$NAME = 'GPVELOCITY') 

character*(*) K$INTERNAL_CMD$NAME 

parameter (K$INTERNAL_CMD$NAME = ’INTERN ALCMD’) 

character*(*) K$PE_INTEGRAL$NAME 

parameter (K$PE_INTEGRAL$NAME = 'PE INTEGRAL') 

character*)*) K$TDLR_VELOCITY$NAME 

parameter (K$TDLR_VELOCIT Y $N AME = 'TDLRVELOCITY') 

character*)*) K$TE_INTEGRAL$NAME 

parameter (K$TE_INTEGRAL$NAME = 'TE INTEGRAL') 

character*)*) K$TE_LIMIT$NAME 

parameter (K$TE_LIMIT$NAME = 'TELIMIT') 

character*)*) K$THETA$NAME 

parameter (K$THETA$NAME = 'THETA') 

character*)*) K$VELOCITY_ERROR$NAME 

parameter (K$VELOCITY_ERROR$NAME = 'VELOCITY ERROR') 

character*)*) K$YE_INTEGRAL$NAME 

parameter (K$ Y E IN T EGRAL$N AME = 'YEINTEGRAL') 

* * * * * jxiodulc CONSTANTS FOIT 
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* Module: CP.FOR 

* Facility: Pluto 

* P-Spec: 2.3 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for CP. 

* 

* List of Routines: 

* subroutine CP 

* function CRC 1 6 

* Title: CP 

* Facility: Pluto 

* Abstract: 

* 1 ) determine the current operational status of the communicator. 

* 2) construct a telemetry data packet. 

* 

* Arguments: None 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 13-jan-1995 Philip Morris (PEM) 

subroutine CP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutput.for' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

*** define local constants *** 

*** the byte count (size in bytes) of the three packets *** 

integer 515 4 K$SP_SIZE 
parameter (K$SP_S1ZE = 129) 

integer^ K$GP_SIZE 
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parameter (K$GP_SIZE = 173) 


integer*4 K$CLP_SIZE 
parameter (K$CLP_S1ZE = 45) 

*** declare local functions *** 
integer* 2 CRC 1 6 

*** declare local variables *** 

integer* 2 seq_temp 

logical* 1 seq_temp_char(2) 

equivalence (seq_temp,seq_temp_char(l)) 

* 1 ) Determine the current operational status of the communicator. 


CSTATUS = 0 

* 2) Construct a telemetry data packet. 


* 2A) Get synchronization pattern. 


PACKET . sync_pattem = COMMSYNCPATTERN 
* 2B) Determine the sequence number. 


seq_temp = MOD(3*(FRAME_COUNTER-l)+ 

& (SUBFRAMECOUNTER-l), 256) 

PACKET.seq_number = seq_temp_char(l) 

* 2C) Prepare the data mask, 

* 2D) Prepare the data, and 

* 2E) Compute the checksum. 

* 

* The 'PACKET' data structure is defined in module EXTERNAL.FOR 


if (SUBFRAME COUNTER .EQ. l)then 
PACKET.DAT A MASK = TF20F1F4'X 

PAC KET. sp . araltitude = ARALTITUDE(O) 

PAC KET. sp . arstatus = ARSTATUS(O) 
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PACKET.sp.atmospherictemp = ATMOSPHERICTEMP 
PACKET, sp. a_acceleration( 1 )= A_ACCELERATION(l ,0) 
PACKET.sp.a_acceleration(2)= A_ACCELERATION(2,0) 

PACKET, sp. a_acceleration(3 )= AACCELERATION (3,0) 

PACKET, sp . a_status( 1 ) = A_STATUS( 1 ,0) 
PACKET.sp.A_STATUS(2) = A_STATUS(2,0) 

PACKET, sp . a_status(3 ) = A_STATUS(3,0) 

PACKET. sp . c status = C STATUS 

PACKET, sp . g_rotation( 1 ) = G_ROTATION( 1 ,0) 

PACKET, sp . g_rotation(2) = G_ROTATION(2,0) 

PACKET . sp . g_r ot ation( 3 ) = G_ROTATION(3,0) 

PACKET, sp . gstatus = G_STATUS 

PACKET.sp.kalt = K_ALT(0) 

PACKET, sp . k_matrix( 1 ) = K_MATR1X( 1,1,0) 

PACKET, sp . k_matrix(2) = K_MATR1X(2,2,0) 

PACKET.sp.k _matrix(3) = K_MATR1X(3,3,0) 

PACKET.sp.tdlr_state( 1 ) = TDLR_STATE( 1 ) 

PACKET.sp.tdlr_state(2) = TDLR_STATE(2) 

PACKET.sp.tdlr_state(3) = TDLR_STATE(3) 

PACKET.sp.tdlr_state(4) = TDLR_STATE(4) 

PACKET.sp.tdlr_status( 1 ) = TDLRSTATU S( 1 ) 
PACKET.sp.tdlr_status(2) = TDLR_STATUS(2) 
PACKET.sp.tdlr_status(3) = TDLR_STATUS(3) 
PACKET.sp.tdlr_status(4) = TDLR_STATUS(4) 
PACKET.sp.tdlrvelocity(l) = TDLR_VELOC1TY(1,0) 
PACKET.sp.tdlr_velocity(2) = TDLR_VELOC1TY(2,0) 
PACKET.sp.tdlr_velocity(3) = TDLR_VELOC1TY(3,0) 
PACKET.sp.tdsstatus = TDSSTATUS 
PACKET.sp.tdsensed = TDSENSED 
PACKET.sp.ts_status( 1 ) = TS_STATUS(1) 

PACKET.sp.ts_status(2) = TS_STATUS(2) 

* vl PR#25 Item 1. Send whole packet. 

* PACKET.sp. checksum = CRC16(PACKET.sp, K$SP_S1ZE) 

PACKET. sp . checksum = CRC 1 6(PACKET.PACKET, K$SP_S1ZE) 

* vl PR#25 End Change. 


else if (SUBFRAME COUNTER .EQ. 2) then 
PACKET.datamask = '007F0002'X 

PACKET.gp.contourcrossed = CONTOUR_CROSSED 
PACKET, gp . cstatus = C_STATUS 

PACKET, gp . gpaltitude = GPALTITUDE(O) 

*** first element of array changes most rapidly *** 

PACKET.gp.gp attitude(l) = GP_ATT1TUDE( 1 , 1, 0) 
PACKET.gp.gp_attitude(2) = GP_ATT1TUDE(2, 1, 0) 
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PACKET. gp . gp_attitude(3 ) = GP_ATTITUDE(3, 1, 0) 

PACKET. gp . gp_attitude(4) = GP_ATTITUDE( 1 , 2, 0) 

PACKET. gp . gp_attitude(5 ) = GP_ATTITUDE(2, 2, 0) 
PACKET.gp.gp_attitude(6) = GP_ATTITUDE(3, 2, 0) 
PACKET.gp.gp_attitude(7) = GP_ATTITUDE( 1,3,0) 

PACKET. gp . gp_attitude( 8 ) = GP_ATTITUDE(2, 3, 0) 

PACKET. gp . gp_attitude(9 ) = GP_ATTITUDE(3 , 3, 0) 

PACKET.gp.gp_phase = GP_PHASE 

PACKET, gp . gp_rotation( 1 ) = GP_ROTATION(2, 1) 

PACKET, gp . gp_rotation(2) = GP_ROTATION(3, 1) 

PACKET. gp . gp_rotation(3 ) = GP_R0TAT10N( 1 , 2) 

PACKET. gp . gp_rotation(4) = GP_R0TAT10N(3, 2) 
PACKET.gp.gp_rotation(5) = GP_R0TAT10N( 1 , 3) 

PACKET. gp . gp_rotation( 6) = GP_R0TAT10N(2, 3) 

PACKET.gp.gp velocity(l) = GP_VEL0C1TY( 1 , 0) 
PACKET.gp.gp_velocity(2) = GP_VEL0C1TY(2, 0) 
PACKET.gp.gp_velocity(3) = GP_VEL0C1TY(3, 0) 

PACKET.gp.velocityerror = VELOC1TYERROR 

* vl PR#25 Item 1. Send whole packet. 

* PACKET. gp. checksum = CRC16(PACKET.gp, K$GP_S1ZE) 

PACKET.gp. checksum = CRC 1 6(PACKET. PACKET, K$GP_S1ZE) 

* vl PR#25 End Change. 


else 

PACKET.datamask = 'E0A00E09'X 

PACKET.clp.ae_cmd( 1 ) = AE_CMD( 1 ) 

PACKET.clp.ae_cmd(2) = AE_CMD(2) 

PACKET.clp.ae_cmd(3) = AE_CMD(3) 

PACKET.clp.aestatus =AE_STATUS 
PACKET.clp.aetemp = AETEMP 
PACKET.clp.chutereleased = CHUTERELEASED 
PACKET.clp.cstatus = CSTATUS 
PACKET.clp.peintegral = PE1NTEGRAL 
PACKET.clp.recmd" = RECMD 
PACKET, c lp .restatus = RESTATUS 

PACKET.clp.teintegral = TE1NTEGRAL 
PACKET.clp.yeintegral = YE1NTEGRAL 

* vl PR#25 Item 1. Send whole packet. 

* PACKET. clp . checksum = CRC16(PACKET.clp, K$CLP_S1ZE) 

PACKET.clp. checksum = CRC 1 6(PACKET.PACKET, K$CLP_S1ZE) 
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*** 


* vl PR#25 End Change. 
*** 


end if 

return 

end 

***** ^ ji_d o f subroutine 

* Title: CRC 16 

* Facility: Pluto 

* Abstract: 

* Compute the Cyclic Redundancy Code of the specified buffer using 

* CRC- 1 6 as the generator polynomial. 

* 

* Arguments: 

* character 5 ^*) message - address of first byte of message. 

* integer*4 bytecount - count of bytes in message. 

* 

* Returns: 

* integer*2 crcl6 - the bit checksum of the specified message. 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

integer 15 2 function CRC 1 6(message, bytecount) 
implicit none 

*** declare the arguments *** 

integer 515 4 bytecount 

byte message(bytecount) 

*** declare local variables *** 

integer*4 i 
logical*2 index 
integer*2 temp 

*** The "signature" table for the CRC- 16 generator polynomial OxAOOl *** 

integer 515 2 crcl6_table(0:255) 

data (ere 1 6_table(i),i= 0, 7) 

& /'0000'X, 'cOc 1 'X, 'c 1 8 1 'X, '0 1 40'X, 

& 'c301'X, '03c0'X, ’0280'X, 'c241'X/ 
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£<3 £<3 ^3^3 £<3 ^3^3 fc= fc= ftsfts fc= fc= ^3^3 fc= £= ^3^3 ^3^3 ^3^3 


_table(i),i= 8, 15) 

/'c60rx, '06c0'X, '0780'X, 'c741'X, 
'0500'X, 'c5cl'X, 'c481'X, '0440'X/ 
_table(i),i= 16, 23) 

/'ccOl'X, 'OccO'X, '0d80'X, ’cd41'X, 
'OflOO'X, 'cfcl'X, 'ce81'X, '0e40'X/ 
_table(i),i= 24, 31) 

/'OaOO'X, 'cacl'X, ’cb81'X, '0b40'X, 
'c901'X, '09c0'X, ’0880’X, 'c841'X/ 
_table(i),i= 32, 39) 

/'d801'X, '18cO'X, ’1980'X, 'd941'X, 
'lbOO'X, 'dbcl'X, 'da81'X, 'la40'X/ 
_table(i),i= 40, 47) 

/'leOO'X, 'decl'X, ’df81'X, 'lf40'X, 
'ddOl'X, 'ldcO'X, 'lc80'X, 'dc41'X/ 
_table(i),i= 48, 55) 

/’1400’X, 'd4cl'X, ’d581'X, '1540'X, 
'd701'X, '17cO'X, ’1680’X, 'd641'X/ 
_table(i),i= 56, 63) 

/'d201'X, '12cO'X, '1380’X, 'd341'X, 
'1100'X, 'dlcl'X, 'd081'X, ’1040’X/ 
_table(i),i= 64, 71) 

/'fflOl'X, '30c0'X, ’3180’X, 'fl41'X, 
’3300’X, 'ficl'X, 'f281'X, '3240'X/ 
_table(i),i= 72, 79) 

/'3600'X, 'f6cl'X, 'f781'X, '3740'X, 
'f501'X, '35cO'X, ’3480’X, 'f441'X/ 
_table(i),i= 80, 87) 

/'3cOO'X, 'fccl'X, 'fd81'X, '3d40'X, 
'ffOl'X, '3fcO'X, '3e80'X, 'fe41'X/ 
_table(i),i= 88, 95) 

/'faOl'X, '3acO'X, '3b80'X, 'fb41'X, 
'3900'X, 'f9cl'X, 'f88 1 'X, '3840'X/ 
_table(i),i= 96,103) 

/’2800’X, 'e8cl'X, 'e981'X, '2940'X, 
’ebOl'X, ’2bcO'X, '2a80'X, 'ea41'X/ 
_table(i),i= 104,1 11) 

/’eeOl'X, '2ecO'X, '2f80'X, 'ef41'X, 
'2d00'X, ’edcl'X, 'ec81'X, '2c40'X/ 
_table(i),i=l 12,1 19) 

/'e401'X, '24cO'X, '2580'X, 'e541'X, 
’2700’X, 'e7cl'X, 'e681'X, '2640'X/ 
_table(i),i= 120,127) 

/'2200'X, 'e2cl'X, 'e381'X, '2340'X, 
'elOl'X, '21cO'X, ’2080'X, 'e041'X/ 
_table(i),i=128,135) 

/'aOOl'X, '60c0'X, ’6180’X, 'al41'X, 
’6300’X, 'a3cl'X, 'a281'X, '6240'X/ 
_table(i),i=l 36,143) 

/’6600’X, 'a6cl'X, 'a781'X, '6740'X, 
'a501'X, '65cO'X, '6480'X, 'a441'X/ 
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fc 5 fc= fc 5 fc=£= fc= fc 5 fc= fc 5 fc= fc 5 


*** 


*** 


data (crc 1 6_table(i),i= 1 44, 1 5 1 ) 

/'6c00'X, 'accl'X, 'ad81'X, '6d40'X, 
'afOl'X, '6fcO'X, '6e80'X, 'ae41'X/ 
data (crcl6_table(i),i=152,159) 

/'aaOl'X, '6acO'X, '6b80'X, 'ab41'X, 
’6900’X, 'a9cl'X, 'a881'X, '6840'X/ 
data (crcl6_table(i),i=160,167) 

/'7800’X, 'b8cl'X, 'b981'X, '7940'X, 
'bbOl'X, '7bcO’X, '7a80'X, 'ba41'X/ 
data (crcl6_table(i),i=168,175) 

/'beOl'X, '7ecO'X, '7f80'X, 'bf41'X, 
'7d00'X, 'bdcl'X, 'bc81'X, '7c40'X/ 
data (crcl6_table(i),i=176,183) 

/'b401'X, '74cO'X, '7580’X, 'b541'X, 
’7700'X, 'b7cl'X, 'b681'X, '7640'X/ 
data (crc 1 6_table(i),i= 184,191) 

/'7200’X, 'b2cl'X, 'b381'X, '7340'X, 
'blOl'X, '71cO'X, '7080’X, 'b041'X/ 
data (crcl6_table(i),i=192,199) 

/’5000’X, ’90c l'X, '9181 'X, '5140'X, 
’930 l'X, '53cO'X, ’5280’X, ’924 l'X/ 
data (crcl6_table(i),i=200,207) 

/’9601’X, '56cO'X, ’5780’X, '974 l'X, 
'5500'X, '95c l'X, '948 l'X, '5440'X/ 
data (crcl6_table(i),i=208,215) 

/'9c01'X, '5ccO'X, '5d80'X, '9d41'X, 
'5fOO'X, '9fcl'X, '9e81'X, '5e40'X/ 
data (crc 1 6_table(i),i=2 16,223) 

/'5a00'X, '9acl'X, '9b81'X, '5b40'X, 
'990 l'X, '59cO'X, '5880'X, '9841 'X/ 
data (crc 1 6_table(i),i=224,23 1 ) 

/'8801'X, '48cO'X, '4980'X, '894 l'X, 
'4b00'X, '8bcl'X, '8a81'X, '4a40'X/ 
data (crcl6_table(i),i=232,239) 

/'4e00'X, '8ecl'X, '8f81'X, '4f40'X, 
'8d01'X, '4dcO'X, '4c80'X, '8c41'X/ 
data (crcl6_table(i),i=240,247) 

/'4400'X, '84c l'X, '85 8 l'X, '4540'X, 
'870 l'X, '47cO'X, '4680'X, '864 l'X/ 
data (crcl6_table(i),i=248,255) 

/'8201'X, '42cO'X, '4380'X, '834 l'X, 
'4100'X, '81c l'X, '808 l'X, '4040'X/ 


crc is a 16-bit unsigned integer value *** 
CRC 16 = 0 


process every byte in the message *** 

do i = 1 ,bytecount 
temp = message(i) 
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index = IE0R(CRC16, temp) ! bitwise xOR lower 8 bits of ere 

index = IAND( index, ’OOFF'X) ! clear top byte of word 
CRC 1 6 = ISHFT(CRC 16,-8) ! bitwise right shift ere 8 times 

CRC16 = 1E0R(CRC 1 6, ere 1 6_table(index)) ! bitwise XOR 16 bits 
end do 

return 

end 

* * * * * of function, 16 

***** of module f P ************************************************** 
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* Module: CRCP.FOR 

* Facilitiy: Pluto 

* P-Spec: 3.3 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for CRCP. 

* 

* List of Routines: 

* subroutine CRCP 

* Title: CRCP 

* Facility: Pluto 

* Abstract: 

* 1) Determine whether or not to release the parachute. 

* 

* Arguments: None. 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original, 
subroutine CRCP 

implicit none 

*** include the global common stores * * *** 

include 'guidancestate.for' 
include 'extemal.for' 

*** include constant definitions *** 

include 'constants. for' 

* The parachute is to be released during the same frame in which the 

* axial engine temperature becomes "HOT" (2). Valid states for 

* CHUTERELEASED are "Chute Attached" (0) and "Chute Released" (1). 

*** 1) Determine whether or not to release the parachute. *** 

if (CHUTERELEASED .eq. K$CHUTE_ ATT ACHED) then 

if (AE TEMP .eq. K$HOT) then 
CHUTERELEASED = K$CHUTE_RELEASED 
end if 

end if 

return 
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end 


***** end of module crcp.for 
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* Module: EXTERN AL.FOR 

* Facility: Pluto 

* Abstract: 

* This module contains the data definitions for the 

* global common data store named EXTERNAL. 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 


*** COMMON block definition *** 
COMMON /EXTERNAL/ 


& 

A COUNTER, 

& 

AE CMD, 

& 

AR COUNTER, 

& 

CHUTE RELEASED, 

& 

FRAME COUNTER, 

& 

G COUNTER, 

& PACKET, 

& 

RE CMD, 

& 

SS TEMP, 

& 

SUBFRAME COUNTER, 

& 

TD COUNTER, 

& 

TDLR COUNTER, 

& 

THERMO TEMP 

*** data type declarations *** 

integer*2 

A COUNTER/ 1:3) 

integer 515 2 

AE CMD(1:3) 

integer* 2 

AR COUNTER 

logical* 1 

CHUTE RELEASED 

integer*4 

FRAME COUNTER 

integer*2 

G COUNTER/ 1:3) 

integer*2 

RE CMD 

integer*2 

SS TEMP 

integer*2 

SUBFRAME COUNTER 

integer*2 

TD COUNTER 

integer*2 

TDLR COUNTER/ 1:4) 

integer*2 

THERMO TEMP 


* Although the specifications define 'packet' as an array of 

* integer*2's, the functional unit CP treats 'packet' as a 

* variant record. The definitions below reserve an array 

* of 256 integer*2 data and overlay the area with a variant 

* record structure. 
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*** the Sensor Processing subframe data field and checksum *** 

structure /sp_data_t/ 
real* 8 araltitude 
logical* 1 arstatus 
real* 8 atmospherictemp 
real*8 a_acceleration(l:3) 
logical* 1 a_status(l :3) 
logical* 1 cstatus 
real*8 g_rotation( 1 :3) 
logical* 1 gstatus 
integer*4k_alt 
integer*4k_matrix( 1 :3) 
logical* 1 tdlr_state( 1 :4) 
logical* 1 tdlr_status(l :4) 
real* 8 tdlr_velocity(l:3) 
logical* 1 tdsstatus 
logical* 1 tdsensed 
logical* 1 ts_status(2) 
integer*2checksum 
end structure 

*** the Guidance Processing subframe data field and checksum *** 

structure /gp_data_t/ 
logical* 1 contourcrossed 
logical* 1 cstatus 
real* 8 gpaltitude 
real*8 gp_attitude(l:9) 
integer*4gp_phase 
real*8 gp_rotation(l:6) 
real*8 gp_velocity(l:3) 
real* 8 velocityerror 
integer*2checksum 
end structure 

*** the Control Law Processing subframe data field and checksum *** 

* vl Changes for AR#23. Item 5. ae temp was changed from logical* 1 to integer*2 

structure /clp_data_t/ 
integer*2ae_cmd( 1 :3) 
logical* 1 aestatus 
integer*2ae_temp 
logical* 1 chutereleased 
logical* 1 cstatus 
real*8 peintegral 
integer*2re_cmd 
logical* 1 restatus 
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real* 8 teintegral 

real* 8 ye_integral 

integer*2checksum 
end structure 

* vl Changes for AR#23. End Change. 

*** the data packet structure *** 

structure /data_packet_t/ 
union 
map 

integer*2 PACKET( 1:256) 
end map 
map 

integer*2 sync_pattem 
logical* 1 seq_number 

integer*4 datamask 
union 
map 

record /sp_data_t/ sp 
end map 
map 

record /gp_data_t/ gp 
end map 
map 

record /clp_data_t/ clp 
end map 
end union 
end map 
end union 
end structure 

*** declare a variable of type PACKET *** 
record /data_packet_t/ PACKET 
of module P,XTKR ^ FOR. 
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* Module: GP.FOR 

* Facility: Pluto 

* P-Spec: 2.2 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for GP. 

* 

* List of Routines: 

* subroutine GP 

* subroutine DER1V ALT 

* subroutine DER1V ATT 

* subroutine DER1V VEL 

* subroutine MULT ATT 

* subroutine MULT VEL 

* subroutine AVG ATT 

* subroutine AVG VEL 

* Title: GP 

* Facility: Pluto 

* Abstract: 

* 1 ) Maintain the history of the vehicle's altitude, velocities, 

* and attitude. 

* 2) Compute the current vehicle altitude, velocities and attitude. 

* 3) Determine if the engines should be switched on or off. 

* 4) Compute the current velocity error. 

* 5) Determe if the predetermined velocity-altitude contour has 

* been crossed. 

* 6) Determine the current guidance phase. 

* 7) Determine the appropriate axial engine control law parameters. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 01 -Dec-1 994 Philip Morris (PEM) 

* v2 10-JAN-1995 Philip Morris (PEM) 

* v3 16-MAR- 1995 Philip Morris (PEM) 

subroutine GP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidance state.for' 
include 'sensoroutputfor' 
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include 'run_parameters.for' 


*** include constant definitions *** 

include 'constants. for' 

*** declare local variables *** 

real*8 temp 

real*8 curaltitude 

real*8 optimalvelocity 

real*8 att_kl(3,3), att_k2(3,3) 

real*8 att_k3(3,3), att_k4(3,3) 

real*8 att_tmp(3,3) 

real*8 vel_kl(3), vel_k2(3), vel_k3(3), vel_k4(3) 

real*8 vel_tmp(3) 

real*8 altkl, alt_k2, alt_k3, alt_k4 

real*8 stepsize 

integer*4 i, j 

* 1) Maintain the history of the vehicle altitude, velocities, 

* and attitude by "rotating variables." 


GP_ALTITUDE(4) = GP_ALTITUDE(3 ) 
GP_ALT1TUDE(3) = GP_ALTITUDE(2) 
GP_ALTITUDE(2) = GP_ALTITUDE( 1 ) 
GPALTITUDE(l) = GPALTITUDE(O) 

GP VELOCIT Y ( 1 , 4) = GP_VELOCITY( 1 , 3) 

GP VELOC1T Y ( 1 , 3) = GP_VELOCITY( 1 , 2) 

GP VELOCIT Y ( 1 , 2) = GP_VELOCITY( 1 , 1) 

GP VELOCIT Y ( 1 , 1) = GP VELOCITY ( 1 , 0) 

GP VELOCITY (2, 4) = GP_VELOCITY(2, 3) 

GP VELOCITY (2, 3) = GP_VELOCITY(2, 2) 

GP VELOCITY (2, 2) = GP_VELOCITY(2, 1) 

GP VELOCITY (2, 1) = GP_VELOCITY(2, 0) 

GP VELOCIT Y (3 , 4) = GP_VELOCITY(3, 3) 
GP_VELOCITY(3, 3) = GP_VELOCITY(3, 2) 

GP VELOCIT Y (3 , 2) = GP_VELOCITY(3, 1) 

GP VELOCIT Y (3 , 1) = GP_VELOCITY(3, 0) 

GP_ATTITUDE( 1 , 1,4) = GP_ATTITUDE( 1 , 1,3) 
GP_ATTITUDE( 1 , 2, 4) = GP_ATTITUDE( 1 , 2, 3) 
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GP_ATTITUDE( 1 , 3, 4) 
GP_ATTITUDE(2, 1, 4) 
GP_ATTITUDE(2, 2, 4) 
GP_ATTITUDE(2, 3, 4) 
GP_ATTITUDE(3 , 1, 4) 
GP_ATTITUDE(3, 2, 4) 
GP_ATTITUDE(3, 3, 4) 


GP_ATTITUDE(1, 3, 3) 
GP_ATTITUDE(2, 1, 3) 
GP_ATTITUDE(2, 2, 3) 
GP_ATTITUDE(2, 3, 3) 
GP_ATTITUDE(3, 1,3) 
GP_ATTITUDE(3, 2, 3) 
GP_ATTITUDE(3, 3, 3) 


GP_ATTITUDE(1, 1,3) 
GP_ATTITUDE( 1 , 2, 3) 
GP_ATTITUDE( 1 , 3, 3) 
GP_ATTITUDE(2 , 1, 3) 
GP_ATTITUDE(2, 2, 3) 
GP_ATT1TUDE(2, 3, 3) 
GP_ATT1TUDE(3, 1,3) 
GP_ATTITUDE(3, 2, 3) 
GP_ATT1TUDE(3, 3, 3) 


GP_ATTITUDE(1 , 1, 2) 
GP_ATT1TUDE(1, 2, 2) 
GP_ATT1TUDE(1, 3, 2) 
GP_ATTITUDE(2, 1, 2) 
GP_ATT1TUDE(2, 2, 2) 
GP_ATT1TUDE(2, 3, 2) 
GP_ATTITUDE(3, 1, 2) 
GP_ATT1TUDE(3, 2, 2) 
GP_ATTITUDE(3, 3, 2) 


GP_ATT1TUDE( 1 , 1,2) = GP_ATT1TUDE( 1 , 1,1) 
GP_ATTITUDE(1, 2, 2) = GP_ATT1TUDE( 1 , 2, 1) 
GP_ATTITUDE(1, 3, 2) = GP_ATT1TUDE( 1 , 3, 1) 
GP_ATTITUDE(2, 1,2) = GP_ATT1TUDE(2, 1,1) 
GP_ATTITUDE(2, 2, 2) = GP_ATTITUDE(2, 2, 1) 
GP_ATTITUDE(2, 3, 2) = GP_ATTITUDE(2, 3, 1) 
GP_ATTITUDE(3 , 1,2) = GP_ATT1TUDE(3, 1,1) 
GP_ATTITUDE(3 , 2, 2) = GP_ATTITUDE(3, 2, 1) 
GP_ATTITUDE(3 , 3, 2) = GP_ATT1TUDE(3, 3, 1) 


GP_ATTITUDE( 1 , 1, 1) = GP_ATTITUDE( 1 , 1, 0) 
GP_ATTITUDE( 1 , 2, 1) = GP_ATT1TUDE( 1 , 2, 0) 
GP_ATT1TUDE( 1 , 3, 1) = GP_ATT1TUDE( 1 , 3, 0) 
GP_ATTITUDE(2, 1,1) = GP_ATTITUDE(2, 1, 0) 
GP_ATTITUDE(2, 2, 1) = GP_ATT1TUDE(2, 2, 0) 
GP_ATTITUDE(2, 3, 1) = GP_ATT1TUDE(2, 3, 0) 
GP_ATTITUDE(3 , 1,1) = GP_ATTITUDE(3, 1, 0) 
GP_ATTITUDE(3 , 2, 1) = GP_ATT1TUDE(3, 2, 0) 
GP_ATTITUDE(3, 3, 1) = GP_ATT1TUDE(3, 3, 0) 


* 2) Compute the current vehicle altitude, velocities and attitude. 




range check the following data elements 




call RANGE_CHECK(GP_ATT1TUDE(1, 1, 2), K$GP_ATT1TUDE$LB, 
& K$GP_ATT1TUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RANGE_CHECK(GP_ATT1TUDE(1, 2, 2), K$GP_ATT1TUDE$LB, 
& K$GP_ATT1TUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RANGE_CHECK(GP_ATT1TUDE(1, 3, 2), K$GP_ATT1TUDE$LB, 
& K$GP_ATT1TUDE$UB, 'GP', K$GP_ATT1TUDE$NAME) 

call RANGE_CHECK(GP_ATT1TUDE(2, 1, 2), K$GP_ATT1TUDE$LB, 
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& K$GP_ATTITUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RANGE_CHECK(GP_ATTITUDE(2, 2, 2), K$GP_ATT1TUDE$LB, 

& K$GP_ATT1TUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RANGE_CHECK(GP_ATTITUDE(2, 3, 2), K$GP_ATTITUDE$LB, 

& K$GP_ATTITUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RANGE_CHECK(GP_ATTITUDE(3 , 1, 2), K$GP_ATTITUDE$LB, 

& K$GP_ATTITUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RANGE_CHECK(GP_ATTITUDE(3, 2, 2), K$GP_ATT1TUDE$LB, 

& K$GP_ATT1TUDE$UB, 'GP', K$GP_ATTITUDE$NAME) 

call RAN GE_CHECK(GP_ATT1TUDE(3 , 3, 2), K$GP_ATT1TUDE$LB, 

& K$GP_ATT1TUDE$UB, 'GP', K$GP_ATT1TUDE$NAME) 

call RAN GE_CHECK(GP_VEL0C1T Y ( 1 , 2), K$GP_VEL0C1TY$LB, 

& K$GP_VEL0C1TY$UB, 'GP', K$GP_VELOCITY$NAME) 

call RANGE_CHECK(GP_VEL0C1TY (2, 2), K$GP_VEL0C1TY$LB, 

& K$GP_VEL0C1TY$UB, 'GP', K$GP_VEL0C1TY$NAME) 

call RANGE_CHECK(GP_VEL0C1TY (3, 2), K$GP_VELOCITY$LB, 

& K$GP_VELOCITY$UB, 'GP', K$GP_VEL0C1TY$NAME) 

call RANGE_CHECK(GP_ALT1TUDE(2), K$GP_ALT1TUDE$LB, 

& K$GP_ALT1TUDE$UB, 'GP', K$GP_ALTITUDE$NAME) 

*** sensor data *** 

call RANGE_CHECK(G_R0TAT10N(1 , 0), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(2, 0), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(3, 0), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(1 , 1), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(2, 1), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RAN GE_CHECK( G ROTATION (3 , 1), K$G_ROTAT ION $LB , 

& K$G_ROT AT ION $UB , 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(1, 2), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(2, 2), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(G_R0TAT10N(3, 2), K$G_ROTAT ION $LB , 

& K$G_R0TAT10N$UB, 'GP', K$G_ROT AT ION $N AME ) 

call RANGE_CHECK(A_ACCELERAT10N(1 , 0), K$A_ACCELERAT10N$LB, 

& K$A_ACCELERAT10N$UB, 'GP', K$A_ACCELERAT10N$NAME) 

call RAN GE_CHECK( A ACCELERATION (2, 0), K$A_ACCELERAT10N$LB, 

& K$A_ACCELERAT10N$UB, 'GP', K$A_ACCELERAT10N$NAME) 

call RAN GE_CHECK( A ACCELERATION (3 , 0), K$A_ACCELERAT10N$LB, 

& K$A_ACCELERAT10N$UB, 'GP', K$A_ACCELERATION$NAME) 

call RANGE_CHECK(A_ACCELERAT10N(1 , 1), K$A_ACCELERAT10N$LB, 

& K$A_ACCELERAT10N$UB, 'GP', K$A_ACCELERAT10N$NAME) 
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call RAN GE_CHECK( AACCELERATION (2, 1), K$ AACCELERATION $LB , 

& K$A_ACCELERATION$UB, 'GP', K$A_ACCELERATION$NAME) 

call RANGE_CHECK( A ACCELERATION (3 , 1), K$A_ACCELERATION$LB, 

& K$A_ACCELERATION$UB, 'GP', K$ A ACCELERATION $NAME) 

call RANGE_CHECK(A_ACCELERATION(l , 2), K$ A ACCELERATION $LB , 

& K$A_ACCELERATION$UB, 'GP', K$A_ACCELERATION$NAME) 

call RAN GE_CHECK( A ACCELERATION (2, 2), K$A_ACCELERATION$LB, 

& K$ A ACCELERATION $UB , 'GP', K$A_ACCELERATION$NAME) 

call RAN GE_CHECK( A ACCELERATION (3 , 2), K$A_ACCELERATION$LB, 

& K$ A ACCELERATION $UB , 'GP', K$A_ACCELERATION$NAME) 

call RANGE_CHECK(TDLR_VELOCITY ( 1 , 0), K$TDLR_VELOCIT Y $LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $NAME) 

call RANGE_CHECK(TDLR_VELOCITY (2, 0), K$TDLR_VELOCITY$LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $NAME) 

call RANGE_CHECK(TDLR_VELOCITY (3, 0), K$TDLR_VELOCITY$LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $N AME) 

call RANGE_CHECK(TDLR_VELOCITY ( 1 , 1), K$TDLR_VELOCITY$LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCITY$NAME) 

call RAN GE_CHECK(TDLR_VELOCITY (2, 1), K$TDLR_VELOCIT Y $LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $NAME) 

call RANGE_CHECK(TDLR_VELOCITY (3, 1), K$TDLR_VELOCITY$LB, 

& K$TDLR_VELOCITY$UB, ’GP', K$TDLR_VELOCIT Y $N AME) 

call RANGE_CHECK(TDLR_VELOCITY ( 1 , 2), K$TDLR_VELOCITY$LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $NAME) 

call RAN GE_CHECK(TDLR_VELOCITY (2, 2), K$TDLR_VELOCIT Y $LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $NAME) 

call RANGE_CHECK(TDLR_VELOCITY (3, 2), K$TDLR_VELOCITY$LB, 

& K$TDLR_VELOCITY$UB, 'GP', K$TDLR_VELOCIT Y $N AME) 

call RANGE_CHECK(AR_ALTITUDE(0), K$AR_ALTITUDE$LB, 

& K$AR_ALTITUDE$UB, 'GP', K$ AR_ALTITUDE$N AME ) 

call RANGE_CHECK(AR_ALTITUDE( 1 ), K$AR_ALTITUDE$LB, 

& K$AR_ALTITUDE$UB, 'GP', K$AR_ALTITUDE$NAME) 

call RANGE_CHECK(AR_ALTITUDE(2), K$AR_ALTITUDE$LB, 

& K$AR_ALTITUDE$UB, 'GP', K$AR_ALTITUDE$NAME) 

* A five step implementation of the RK method. The functions 

* deriv_att(), deriv_vel(), and deriv_alt() are described below. 

* 

* The interval begins at the current frame minus 2 frames. 

* 

* 1. Compute the first estimate of the incremental value for 

* GP ATTITUDE, GP VELOCITY, and GP ALTITUDE based upon the 

* rate of change at the beginning of the interval 

* (2 frames ago): 

* 

* estimate = rate_of_change * step_size 
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step size = 2 * DELTAT 

call deriv_att(att_k 1 , GPATTITUDE) 1,1,2), 2) 
call mult_att(att_kl, step size) 


* vl Changes for AR#23. Item 13. "attkl" changed to "velkl" 

call deriv_vel(vel_kl , GP_VEL0C1TY(1,2), GP_ATTITUDE(1,1,2), 2) 
call mult_vel(vel_kl, step size) 


* vl Changes for AR#23. End Change. 

call deriv_alt(alt_kl , GP_ALTITUDE(2),GP_VELOCITY(l,2), 

& GP_ATTITUDE(1,1,2), 2) 

altkl = altkl * step size 

* 2. Compute the second estimate of the incremental value for 

* GPATTITUDE, GPVELOCITY, and GP ALT1TUDE based upon the 

* rate of change at the midpoint of the first estimate kl : 

call avg_att(att_tmp, GP ATTITUDE) 1,1,2), att kl) 
call deriv_att(att_k2, att tmp, 1) 
call mult_att(att_k2, step size) 

call avg_vel(vel_tmp, GP_VEL0C1TY(1,2), vel kl) 
call deriv_vel(vel_k2, vel tmp, att tmp, 1) 

* v2 Changes for PR#24. Item 2. Changed division placement. 

* call mult_vel(att_k2, step size) 
call mult_vel(vel_k2, step size) 

* call deriv_alt(alt_k2, (GP_ALTITUDE(2) + alt kl )/2, 

* & vel tmp, att tmp, 1) 

call deriv_alt(alt_k2, (GP_ALTITUDE(2) + alt_kl/2), 

& vel tmp, att tmp, 1) 

alt_k2 = alt_k2 * STEP SIZE 

* v2 Changes for AR#24. End Change. 

* 3. Compute the third estimate of the incremental value for 

* GP ATTITUDE, GP VELOCITY, and GP ALT1TUDE based upon the 

* rate of change at the midpoint of the second estimate k2: 
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call avg_att(att_tmp, GP_ATTITUDE( 1 , 1 ,2), att_k2) 
call deriv_att(att_k3, atttmp, 1) 
call mult_att(att_k3, step size) 

call avg_vel(vel_tmp, GP_VEL0CITY(1,2), vel_k2) 
call deriv_vel(vel_k3, veltmp, att tmp, 1) 
call mult_vel(vel_k3, step size) 


* v2 Changes for PR#24. Item 2. Changed division placement. 

* call deriv_alt(alt_k3 , (GP_ALT1TUDE(2) + alt_k2)/2, 

* & vel tmp, att tmp, 1) 

call deriv_alt(alt_k3, (GP_ALTITUDE(2) + alt_k2/2), 

& vel tmp, att tmp, 1) 

* v2 Changes for AR#24. End Change. 

alt_k3 = alt_k3 * STEP SIZE 

* 4. Compute the fourth estimate of the incremental value for 

* GP ATTITUDE, GP VELOCITY, and GP ALTITUDE based upon the 

* the rate-o f-change at the third estimate k3 : 

do i = 1,3 
do j = 1,3 

att_tmp(i,j) = GP_ATTITUDE(i, j, 2) + att_k3(i, j) 
end do 
end do 

call deriv_att(att_k4, att tmp, 0) 
call mult_att(att_k4, step size) 

do i = 1,3 

veltmp(i) = GPVELOCITY (i,2) + vel_k3(i) 
end do 


* vl Changes for AR#23. Item 15. 4th parameter changed to "0" 


call deriv_vel(vel_k4, vel tmp, att tmp, 0) 

* v2 Changes for PR#24. Item 4. Changed att k to vel_k4. 

* call mult_vel(att_k4, step size) 
call mult_vel(vel_k4, step size) 

* v2 Changes for AR#24. End Change. 
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* vl Changes for AR#23. End Change. 

call deriv_alt(alt_k4, (GP_ALTITUDE(2) + alt_k3), 

& veltmp, atttmp, 0) 

alt_k4 = alt_k4 * STEP S1ZE 

* 5. Perform a weighted average of the four previously computed 

* estimates of the new value for GP ATTITUDE, GPVELOCITY, and 

* GPALTITUDE. 

* 

* Note, the syntax (*, x) and (*, *, x) represent the xth history of 

* the data element. 

* GP_ATT1TUDE(*, *, 0) = GP_ATT1TUDE(*, *, 2) + 

* & (l/6)(att_kl + 2*(att_k2 + att_k3) + att_k4) 

do i = 1,3 
do j = 1,3 

att_tmp(i,j) = (att_k2(i,j) + att_k3(i,j)) * 2.0 
att_tmp(i,j) = (att_tmp(i,j) + attk 1 ( i j ) + 

& att_k4(i,j)) / 6.0 

GP_ATTITUDE(i, j , 0) = GP_ATTlTUDE(i, j , 2) + att_tmp(i,j) 
end do 
end do 

* GP VELOCITY (*, 0) = GP_VELOClTY(*, 2) + 

* & (l/6)(vel_kl + 2*(vel_k2 + vel_k3) + vel_k4) 

do i = 1,3 

vel_tmp(i) = (vel_k2(i) + vel_k3(i)) * 2.0 
vel_tmp(i) = (vel_tmp(i) + vel_kl(i) + vel_k4(i)) / 6.0 
GP VELOCITY (i, 0) = GP_VELOClTY(i, 2) + vel_tmp(i) 
end do 

* GPALTITUDE(O) = GP_ALTITUDE(2) + 

* & (l/6)(alt_kl + 2*(alt_k2 + alt_k3) + alt_k4) 

GPALTITUDE(O) = GP_ALTITUDE(2) + 

& (altkl + 2.0*(alt_k2 + alt_k3) + alt_k4) / 6.0 

*** establish the "final" rotation matrix *** 
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GPROT AT ION( 1 , 1)= 0 
GPROT AT ION( 1 , 2) 

GPROT AT ION( 1 , 3) 

GP_ROTATION(2, 1) 

GP_ROTATION(2, 2) 

GP_ROTATION(2, 3) 

GP_ROTATION(3, 1)= G_ROTATION(2, 0) 
GP_ROTATION(3, 2) 

GP_ROTATION(3, 3) 


G_ROTATION(3, 0) 
-G_ROTATION(2, 0) 
-G_ROTATION(3, 0) 
0 

G_ROTATION(l 


-G_ROTATION(l, 

0 


0 ) 


0 ) 


* 3) Determine if the engines should be switched on or off. 




range check the current altitude 




call RANGE_CHECK(GP_ALTITUDE(0), K$GP_ALTITUDE$LB, 

& K$GP_ALTITUDE$UB, 'GP', K$GP_ALT1TUDE$NAME) 

*** range check the current x-axis vehicle velocity **** 


call RAN GE_CHECK( GP VELOC1T Y ( 1 , 0), K$GP_VELOCITY$LB, 

& K$GP_VELOCITY$UB, 'GP', K$GP_VELOClTY$NAME) 


if (AE SW1TCH .EQ. K$AX1AL_ENG1NES_ARE_0FF) then 
if (RE SW1TCH .EQ. K$ROLL_ENGlNES_ARE_ON) then 
if (TD SENSED .EQ. K$TOUCH_DOWN_NOT_SENSED) then 
if (GP ALTITUDE(O) .LE. ENGlNES_ON_ ALTITUDE) then 
AESW1TCH = K$ AX1ALEN G1NESAREON 
FRAMEENG1NES1GN1TED = FRAMECOUNTER 
end if 
end if 
end if 
else 

the axial engines are "on" *** 




if (TD SENSED .EQ. K$TOUCH_DOWN_SENSED) then 
AESW1TCH = K$AX1AL_ENG1NES_ARE_0FF 
RESW1TCH = K$ROLL_EN GIN E SAREOFF 
else 


touch down "not sensed" *** 


* vl PR#27 Item 3. Included a MAX function. 

* if (GP ALTITUDE(O) .LE. DROP HE1GHT) then 

* temp = 2*GRAV1TY*GP_ALT1TUDE(0) 

* call N EG_V AL U E_CHECK(temp , 'GP') 
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if (GP ALTITUDE(O) .LE. DROPHEIGHT) then 
temp = 2 * GRAVITY * MAX(0.0D0, GP ALTITUDE(O)) 

* vl PR#27 End Change 


if (sqrt(temp)+GP_VELOCITY ( 1 ,0) .LE. 

& MAX_N ORMAL V ELOCIT Y) then 

AESWITCH = K$AXIAL_ENGINES_ARE_OFF 
RESWITCH = K$ROLL_EN GINESAREOFF 
end if 
end if 
end if 
end if 

* 4) Compute the current velocity error. 


*** compute the optimal velocity *** 

*** convert GP ALTITUDE from meters to kilometers *** 
curaltitude = GP ALTITUDE(O) / 1000.0 
do i = 1 , 100 

if (CONTOUR ALTITUDE(i) .EQ. cur altitude) then 

*** found an exact match in the table *** 

optimalvelocity = CONTOURVELOCITY(i) 

goto 100 ! early exit 

else if (CONTOUR ALTITUDE(i) .GT. cur altitude) then 
if (i .GT. 1) then 

*** interpolate between i-1 and i *** 

*** check for potential divide by zero condition *** 

call ZERO_CHECK(CONTOUR_ALTITUDE(i)- 
& CONTOUR ALTITUDE(i-l), 'GP') 

*** interpolation formula *** 

optimalvelocity = CONTOURVELOCITY(i-l) + 

& ((CONTOUR VELOCITY (i) - CONTOUR VELOCITY(i-l)) / 

& (CONTOUR ALTITUDE(i) - CONTOUR ALTITUDE(i-l)) * 

& (cur altitude - CONTOUR_ALTITUDE(i-l ))) 
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goto 100 


! early exit 


else 

*** Extrapolate for altitude < smallest value in table entries *** 

*** check for potential divide by zero condition *** 

call ZERO_CHECK(CONTOUR_ALTITUDE(2) - 
& CONTOUR ALTITUDE(l), 'GP') 

*** Extrapolation formula *** 

optimalvelocity = CONTOUR VELOClTY(l) - 
& ((CONTOUR_VELOClTY(2) - CONTOUR VELOCITY(l)) / 

& (CONTOUR_ALTITUDE(2) - CONTOUR_ALTlTUDE( 1 )) ) * 

& (CONTOUR_ALTITUDE( 1 ) - curaltitude) 

goto 1 00 ! early exit 

end if 
else 

*** CONTOUR ALTITUDE(i) < cur altitude 

if ((CONTOUR ALTlTUDE(i) .EQ. 0) .OR. (i .EQ. 100)) then 

*** Extrapolate for altitude > largest value in table entries *** 

*** note, i points to first (lowest) "0" entry in the table *** 

*** check for potential divide by zero condition *** 

call ZERO_CHECK(CONTOUR_ALTlTUDE(i-l) - 
& CONTOUR_ALTlTUDE(i-2), 'GP') 

*** Extrapolation formula *** 

optimalvelocity = CONTOURVELOClTY(i-l) + 

& ((CONTOUR VELOC1TY (i-1 ) - CONTOUR_VELOClTY(i-2)) / 
& (CONTOUR_ALTlTUDE(i- 1 ) - CONTOUR_ALTlTUDE(i-2)) ) * 
& (cur altitude - CONTOUR ALTlTUDE(i-l)) 

goto 1 00 ! early exit 

end if 
end if 
end do 

100 continue 
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*** convert optimalvelocity from km/sec to m/sec *** 
optimalvelocity = optimal velocity * 1000.0 
*** compute the velocity error *** 

VELOCITYERROR = GP_VELOCITY(l, 0) - optimal velocity 

* 5) Determine if the predetermined velocity-altitude contour has 

* been crossed. 


* vl Changes for AR#23. Item 17. >= changed to <= 


if (GP ALTITUDE(O) .LE. ENG1NES ON ALTITUDE) then 
if (CONTOUR CROSSED .EQ. K$CONTOUR_NOT_CROSSED) then 
if (VELOCITY ERROR .GE. 0) then 
CONTOURCROSSED = K$CONTOUR_CROSSED 
end if 
end if 
end if 


* vl Changes for AR#23. End Change. 

* 6) Determine the current guidance phase. 

go to (1010, 1020, 1030, 1040, 2000), GP_PHASE 


* vl Changes for AR#23. Item 33. Added default goto 

go to 2000 

* vl Changes for AR#23. End Change. 


GP PHASE == 1 




1010 continue 

*** trans from 1 to 2 when the "engines on altitude" is reached *** 

if (GP ALTITUDE(O) .LE. ENGINES ON ALTITUDE) then 
GPPHASE = 2 
end if 
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goto 2000 


GP PHASE == 2 




1 020 continue 

*** trans from 2 to 5 when touch down is sensed *** 

if (TD SENSED .EQ. K$TOUCH_DOWN_SENSED) then 
GPPHASE = 5 
else 


*** trans from 2 to 3 when the engines are hot and the chute is released *** 


if (AE TEMP .EQ. K$HOT) then 
if (CHUTERELEASED .EQ. K$CHUTE_RELEASED) then 
GPPHASE = 3 
end if 
end if 
end if 


goto 2000 


*** GP PHASE 


3 *************************** 


1030 continue 


*** trans from 3 to 5 when touch down is sensed *** 

if (TD SENSED .EQ. K$TOUCH_DOWN_SENSED) then 
GPPHASE = 5 
else 


*** trans from 3 to 5 when the TD sensor fails and altitude too low *** 
*** trans from 3 to 4 when the TD sensor healthy and altitude too low *** 


if (GP ALTITUDE(O) .LE. DROPHEIGHT) then 

if (TDS STATUS .EQ. K$FA1LED) then 
GPPHASE = 5 
else 

* vl PR#27 Item 3. Included a MAX function. 

* temp = 2 * GRAVITY * GP ALTITUDE(O) 

* call N EG_V AL U E_CHECK(temp , 'GP') 

temp = 2 * GRAVITY * MAX(0.0D0, GP ALTITUDE(O)) 

* vl PR#27 End Change 
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if (sqrt(temp)+GP_VELOCITY(l,0) .LE. 

& MAXNORMALVELOCITY) then 

GPPHASE = 4 
end if 
end if 
end if 
end if 

goto 2000 

GP PHASE == 4 *************************** 

1 040 continue 

*** trans from 4 to 5 when touch down is sensed *** 

if (TD SENSED .EQ. K$TOUCH_DOWN_SENSED) then 
GPPHASE = 5 
else 

*** trans from 4 to 5 when the TD sensor fails *** 

if (TDS STATUS .EQ. K$FA1LED) then 
GPPHASE = 5 
end if 
end if 

2000 continue 

* 7) Determine the appropriate axial engine control law parameter index. 

*** ]\[ 0 te, the optimalvelocity is computed above during the computing of 
*** the current velocity error. 

if (CL .EQ. KSFIRST) then 
if (optimal velocity .EQ. DROPSPEED) then 
if (GP_VEL0C1TY(1, 0) .LT. DROP SPEED) then 
CL = KSSECOND 
TEINTEGRAL = 0 
end if 
end if 
end if 

return 

end 

^ o f subroutine (jr J? 
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* Title: DERIVATT 

* Facility: Pluto 

* Abstract: 

* C ompute the derivative of the vehicle attitude. 

* rate-of-change = deriv_att(attitude, i) 

* 

* Arguments: 

* result array (1..3, 1..3) of real*8 The computed derivative. 

* att array (1..3, 1..3) ofreal*8 The attitude structure 

* index integer*4 The history index 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 01 -Dec-1 994 Philip Morris (PEM) 

subroutine DERIV ATT (result, att, index) 

implicit none 

*** define arguments *** 

real*8 att( 1 : 3 , 1 : 3 ) 

real*8 result(l:3,l:3) 

integer 515 4 index 

*** include the global common stores *** 
include 'sensor output.for' 


* vl Changes for AR#23. Item 18. Replaced pv, qv, rv with rotation variables 


result(l,l) = G_R0TAT10N(3, index) * att(2,l) + 

& (-G_R0TAT10N(2, index) * att(3 , 1 )) 
result(l,2) = G_R0TAT10N(3, index) * att(2,2) + 

& (-G_R0TAT10N(2, index) * att(3,2)) 
result(l,3) = G_R0TAT10N(3, index) * att(2,3) + 

& (-G_R0TAT10N(2, index) * att(3,3)) 

result(2, 1 ) = (-G_R0TAT10N(3, index) * att( 1,1)) + 
& (G_R0TAT10N( 1 , index) * att(3, 1 )) 
result(2,2) = (-G_R0TAT10N(3, index) * att(l,2)) + 
& (G_R0TAT10N( 1 , index) * att(3,2)) 
result(2,3) = (-G_R0TAT10N(3, index) * att(l,3)) + 
& (G_R0TAT10N(1, index) * att(3,3)) 
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result(3,l) = G_R0TATI0N(2, index) * att(l,l) + 

& (-G_ROTATION( 1 , index) * att(2, 1 )) 
result(3,2) = G_R0TATI0N(2, index) * att(l,2) + 

& (-G_ROTATION( 1 , index) * att(2,2)) 
result(3,3) = G_R0TATI0N(2, index) * att(l,3) + 

& (-G_ROTATION( 1 , index) * att(2,3)) 

*** 

* vl Changes for AR#23. End Change. 

return 

end 

of subroutine DRR | \/ ,/VTT 

* Title: DERIV VEL 

* Facility: Pluto 

* Abstract: 

* Compute the derivative of the vehicle velocity. 

* rate-of-change = deriv_vel(velocity, attitude, i) 

* 

* Arguments: 

* result array (1..3) of real*8 The computed derivative. 

* vel array (1..3) of real*8 The velocity vector 

* att array (1..3, 1..3) ofreal*8 The attitude structure 

* index integer*4 The history index 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 01 -Dec-1 994 Philip Morris (PEM) 

subroutine DERIV_VEL(result, vel, att, index) 

implicit none 

*** define arguments *** 

real*8 att( 1 : 3 , 1 : 3 ) 

real*8 result(l:3) 

real*8 vel(l:3) 

integer*4 index 

*** include the global common stores *** 

include 'guidance state.for' 
include 'sensoroutputfor' 
include 'run_parameters.for' 
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* vl Changes for AR#23. Item 19. Relpaced pv, qv, rv with rotation variables 
*** 

*** declare local variables *** 
real*8 temp(3) 

*** execution begins here *** 

*** 

* vl Changes for AR#23. Item 20. Changed index values for temp 
*** 

temp( 1) = TDLR_VELOCITY(l, index) - vel(l) 
temp(2) = TDLR_VELOCITY(2, index) - vel(2) 
temp(3) = TDLR_VELOCITY(3, index) - vel(3) 

result( 1) = G_ROTATION(3,mdex)*vel(2) + 

& (-G_ROTATION(2,index)*vel(3)) + 

& GRAVITY * att( 1 ,3) + A_ACCELERATION(l, index) + 

& K_MATRIX( 1 , 1 , index) * tempi 1 ) + 

& K_MATRIX( 1 ,2, index) * temp(2) + 

& K_MATRIX( 1,3, index) * temp(3) 


result(2) = -G_ROTATION(3,index)*vel(l) + 

& G_ROTATION( 1, index) *vel(3) + 

& GRAVITY * att(2,3) + A_ACCELERATION(2, index) + 

& K_MATRIX(2, 1 , index) * tempi 1 ) + 

& K_MATRIX(2,2,index) * temp(2) + 

& K_MATRIX(2,3,mdex) * temp(3) 


result(3) = G_ROTATION(2,index)*vel(l) + 

& (-G_ROTATION(l,index)*vel(2)) + 

& GRAVITY * att(3,3) + A_ACCELERATION(3, index) + 

& K_MATRIX(3 , 1 , index) * tempi 1 ) + 

& K_M ATRIX(3 ,2 ,index) * temp(2) + 

& K_MATRIX(3,3,index) * temp!3) 


*** 

* vl Changes for AR#23. End Change. 

*** 

return 

end 

***** of Subroutine *************************************** 

* Title: DERIV ALT 

* Facility: Pluto 

* Abstract: 
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* C ompute the derivative of the vehicle altitude. 

* rate-of-change = deriv_att(attitude, index) 

* 

* Arguments: 

* result real*8 The computed derivative. 

* alt real* 8 The altitude 

* vel array (1..3) of real*8 The velocity vector 

* att array (1..3, 1..3) of real*8 The attitude structure 

* index integer*4 The history index 


* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 


subroutine DERIVALT (result, alt, vel, att, index) 

implicit none 

*** define arguments *** 

real*8 alt 

real*8 att( 1 : 3 , 1 : 3 ) 

real*8 result 

real*8 vel(l:3) 

integer*4 index 


*** include the global common stores *** 

include 'guidance state.for' 
include 'sensoroutputfor' 

*** execution begins here *** 

result = -att(l,3)*vel(l) + (-att(2,3)*vel(2)) + 

& (-att(3,3)*vel(3)) + 

& K ALT (index)* (ARALTITUDE(index) - alt) 


return 

end 

Of subroutine DKR I y\ [ y 

* Title: MULT ATT 

* Facility: Pluto 

* Abstract: 

* Multiply a 3x3 array by a scaler, result -> 3x3 array. 

* mat = mat * scaler 

* 

* Arguments: 

* att array (1..3, 1..3) of real*8 The attitude structure 
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factor real* 8 


The scalar multiplier 


* 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 01 -Dec-1 994 Philip Morris (PEM) 

subroutine MULT_ATT(att, factor) 

implicit none 

*** define arguments *** 

real*8 att( 1 : 3 , 1 : 3 ) 

real*8 factor 

*** execution begins here *** 

* vl Changes for AR#23. Item 22. Changed att index values 

att( 1,1) = att( 1,1) * factor 

att(l,2) = att(l,2) * factor 

att( 1,3) = att( 1,3) * factor 

att(2,l) = att(2,l) * factor 

att(2,2) = att(2,2) * factor 

att(2,3) = att(2,3) * factor 

att(3,l) = att(3,l) * factor 

att(3,2) = att(3,2) * factor 

att(3,3) = att(3,3) * factor 

return 

end 

*** 

* vl Changes for AR#23. End Change. 

of subroutine T\/T I J T ATT 

* Title: MULT VEL 

* Facility: Pluto 

* Abstract: 

* Multiply a 1x3 vector by a scaler, result -> vector 

* vector = vector * scaler 

* 

* Arguments: 

* att array (1..3) of real* 8 The velocity structure 

* factor real* 8 The scalar multiplier 


C-57 



* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

subroutine MULT_VEL(vel, factor) 

implicit none 

*** define arguments *** 

real*8 vel(l:3) 

real*8 factor 

*** execution begins here *** 

vel(l) = vel(l) * factor 

vel(2) = vel(2) * factor 

vel(3) = vel(3) * factor 

return 

end 

of subroutine \/ p j 

* Title: AVG ATT 

* Facility: Pluto 

* Abstract: 

* Add two 3x3 array's 

* result = (matl + mat2 / 2) 

* 

* Arguments: 

* result array (1..3, 1..3) of real*8 the result attitude structure 

* attl array (1..3, 1..3) of real*8 an attitude structure 

* att_2 array (1..3, 1..3) of real*8 an attitude structure 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 01 -Dec-1 994 Philip Morris (PEM) 

subroutine AVG_ATT(result, att l, att_2) 

implicit none 

*** define arguments *** 

real*8 result(l:3, 1:3) 

real*8 att_l(l:3, 1:3), att_2(l:3, 1:3) 
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*** execution begins here *** 


* vl Changes for PR#23. Item 14 & 21. Function no longer averages but 

* divides one element by 2 

* v2 Changes for PR#24. Item 1. Changed index values. 

* result(l,l) = att_ 1(1,1) + att_2(l,l) / 2.0 

* result(l,2) = att_ 1(1,1) + att_2(l,l) / 2.0 

* result(l,3) = att_ 1(1,1) + att_2(l,l) / 2.0 

* 

* result(2, 1 ) = att l (2, 1 ) + att_2(2, 1 ) / 2.0 

* result(2,2) = att l (2, 1 ) + att_2(2, 1 ) / 2.0 

* result(2,3) = att l (2, 1 ) + att_2(2, 1 ) / 2.0 

* 

* result(3,l) = att_l(3,l) + att_2(3,l) / 2.0 

* result(3,2) = att_ 1(3,1) + att_2(3,l) / 2.0 

* result(3,3) = att_ 1(3,1) + att_2(3,l) / 2.0 

result(l,l) = att_ 1(1,1) + att_2(l,l) / 2.0 
result(l,2) = att_l(l,2) + att_2( 1,2) / 2.0 

result(l,3) = attl (1,3) + att_2(l,3) / 2.0 

result(2,l) = att_l(2,l) + att_2(2,l) / 2.0 
result(2,2) = att_l(2,2) + att_2(2,2) / 2.0 
result(2,3) = att_l(2,3) + att_2(2,3) / 2.0 

result(3,l) = att_l(3,l) + att_2(3,l) / 2.0 
result(3,2) = att_ 1(3,2) + att_2(3,2) / 2.0 
result(3,3) = att_l(3,3) + att_2(3,3) / 2.0 

* v2 Changes for PR#24. End Change. 

* vl Changes for PR#23. End Change. 

return 

end 

of subroutine AV (j 2 ^. t ' t ' 

* Title: AVG VEL 

* Facility: Pluto 

* Abstract: 

* Add two 1x3 vector's 

* result = (vec 1 + vec2 / 2) 

* 

* Arguments: 
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* result array (1.. 3) of real* 8 the result velocity structure 

* vei l array (1..3) of real*8 an velocity structure 

* vel_2 array (1..3) of real*8 an velocity structure 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 01 -Dec-1 994 Philip Morris (PEM) 

subroutine AVG_VEL(result, vei l, vel_2) 

implicit none 

*** define arguments *** 

real*8 result(l:3) 

real*8 vel_l(l:3), vel_2(l:3) 

*** execution begins here *** 

*** 

* vl Changes for AR#23. Item 14 & 21. Function no longer averages but 

* divides one element by 2 
*** 

result(l) = vel_l(l) + vel_2(l) / 2.0 
result(2) = vel_l(2) + vel_2(2) / 2.0 
result(3) = vel_l(3) + vel_2(3) / 2.0 

*** 

* vl Changes for AR#23. End Change. 

*** 

return 

end 

* * * * * of subroutine AV Cj V r I ***************************************** 

***** enc j of ruodule (jP ************************************************** 
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* Module: GPSF.FOR 

* Facility: Pluto 

* P-Spec: 2 

* Abstract: 

* This module contains the entry for the guidance processing 

* subframe. 

* 

* List of Routines: 

* subroutine GPSF 

* Title: GPSF 

* Facility: Pluto 

* Abstract: 

* This routine provides control of the Guidance Processing SubFrame 

* processing. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

subroutine GPSF 
implicit none 

*** execution begins here *** 

call GCS S1M RENDEZVOUS 
call GP 
call CP 

return 

end 

enc j Qjp module GPSF F'O^R. ^^^^^^^^^^*®*'®*'®*'®**®*'®*'^*®*'®*'®*'®*'®*'®*'®*'^*®*'®*'®*'®**®*^*'®**®*'®*'®*'®*'®*^*'®**®*^*'®*'®**®* 
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* Module: GSP.FOR 

* Facility: Pluto 

* P-Spec: 1.4 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for GSP. 

* 

* List of Routines: 

* subroutine GSP 

* Title: GSP 

* Facility: Pluto 

* Abstract: 

* 1 ) maintain the history of the vehicle rotation rates 

* 2) determine the operational status of the gyroscope sensors 

* 3) Report the current vehicle rotation rates along each of the 

* vehicle's three axes. 

* 

* Arguments: None 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

subroutine GSP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutputfor' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

*** declare local variables *** 

* vl Changes for AR#23. Item 23. counter type changed from real* * 8 to integer*2 

integer*2 counter 
real*8 temp 

integer*4 i 
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* vl Changes for AR#23. End Change. 

*** 

* 1 ) Maintain the history of the vehicle rotation rates by "rotating 

* variables." 


G_ROTATION(l, 4) = G_ROTATION(l, 3) 
G_R0TAT10N(1, 3) = G_R0TAT10N(1, 2) 
G_R0TAT10N( 1 , 2) = G_R0TAT10N( 1 , 1) 
G_R0TAT10N(1, 1) = G_R0TAT10N(1, 0) 

G_R0TAT10N(2, 4) = G_ROTATION(2, 3) 
G_R0TAT10N(2, 3) = G_R0TAT10N(2, 2) 
G_R0TAT10N(2, 2) = G_R0TAT10N(2, 1) 
G_R0TAT10N(2, 1) = G_ROTATION(2, 0) 

G_R0TAT10N(3, 4) = G_ROTATION(3, 3) 
G_R0TAT10N(3, 3) = G_R0TAT10N(3, 2) 
G_R0TAT10N(3, 2) = G_R0TAT10N(3, 1) 
G_R0TAT10N(3, 1) = G_ROTATION(3, 0) 

* 2) determine the operational status of the gyroscope sensors. 


GSTATUS = K$HEALTHY 

* 3) Report the current vehicle rotation rates along each of the 

* vehicle's three axes. 


*** range check the atmospheric temperature **** 

call RANGE_CHECK(ATM0SPHER1C_TEMP,K$ATM0SPHER1C_TEMP$LB, 

& K$ATM0SPHER1C_TEMP$UB,'GSP', K$ AT MO SPEIERICT EMP$N AME ) 

* The raw sensor data stored in G COUNTER represents the vehicle rate 

* of rotation about a specific axis. The sensor data is 

* stored in a modified sign magnitude format. The lower 14-bits 

* represent the magnitude of the rotation and the most significant 

* bit (bit 15) represents the sign. Bit 14 is not used. A 

* positive value of G COUNTER indicates a positive rotation about 

* the vehicle axis consistent with a right handed coordinate system, 

* while a negative value indicates a negative rotation consistent 

* with a right handed coordinate system. 
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temp = (G3 * ATMOSPHERICTEMP) + (G4 * ATMOSPHERIC_TEMP**2) 
do 100 i= 1,3 

*** convert the raw sensor *** 

* Convert the raw sensor data from the modified sign magnitude 

* format into an appropriate format for use by the target CPU, in 

* this case two's complement. Positive values are represented in 

* the same fashion in sign magnitude and two's complement, however, 

* negative sensor values must be massaged. 

* 

* Transfer the magitude of the rotation from GCOUNTER to the local 

* data element named counter by masking bits 14 and 15 from 

* G COUNTER. If G COUNTER bit 15 is clear, the data element counter 

* now contains the properly converted value. If G COUNTER bit 15 is 

* set, the value of data element counter must be negated. 

*** clear the two most significant bits (bits 15,14) *** 

counter = IAND(G_COUNTER(i), '3FFF'X) 

*** if the bit was set, then convert value to two's complement *** 

if (BTEST(G_COUNTER(i), 15) .EQ. .TRUE.) then 
counter = 0 - counter 
end if 

*** now, compute the vehicle rotation from the sensor data *** 

G_ROTATION(i, 0) = G OFFSET(i) + 

& (G_GAIN_0(i) + temp) * counter 

100 continue 

return 

end 

end of module (j§p 
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* Module: GUIDANCESTATE.FOR 

* Facility: Pluto 

* Abstract: 

* This module contains the data definitions for the 

* global common data store named GUIDANCESTATE. 


* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 


**** COMMON block definition *** 
COMMON /GUIDANCESTATE/ 


& 

A STATUS, 

& 

AE STATUS, 

& 

AE SWITCH, 

& 

AE TEMP, 

& 

AR STATUS, 

& 

C STATUS, 

& 

CL, 

& 

CONTOUR CROSSED, 

& 

FRAME BEAM UNLOCKED, 

& 

FRAME ENGINES IGNITED, 

& 

G STATUS, 

& 

GP ALTITUDE, 

& 

GP ATTITUDE, 

& 

GP PHASE, 

& 

GP ROTATION, 

& 

GP VELOCITY, 

& 

INTERNAL CMD, 

& 

K ALT, 

& 

K MATRIX, 

& 

PE INTEGRAL, 

& 

RE STATUS, 

& 

RE SWITCH, 

& 

TDLR STATE, 

& 

TDLR STATUS, 

& 

TDS STATUS, 

& 

TE INTEGRAL, 

& 

TE LIMIT, 

& 

THETA, 

& 

TS STATUS, 

& 

VELOCITY ERROR, 

& 

YE INTEGRAL 

*** data type declarations *** 

logical* 1 

A STATUS(1:3, 0:3) 

logical* 1 

AE STATUS 

logical*! 

AE SWITCH 
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integer*2 AETEMP 
logical* 1 AR_STATUS(0:4) 
logical* 1 CSTATUS 
integer*2 CL 

logical* 1 CONTOURCROSSED 

integer*4 FRAME_BEAM_UNLOCKED( 1 :4) 

integer*4 F R AME EN GIN E SIGN ITED 

logical* 1 GSTATUS 

real*8 GP_ALTITUDE(0:4) 

real*8 GPATTITUDE) 1 :3, 1 :3, 0:4) 

integer*4 GP PHASE 

real*8 GP_ROTATION(l:3, 1:3) 

real*8 GP_ VELOCITY) 1:3, 0:4) 

real*8 INTERNALCMD) 1 :3) 

integer*4 K_ALT(0:4) 

integer*4 K_MATRIX)1:3, 1:3, 0:4) 

real*8 PEINTEGRAL 

logical* 1 RESTATUS 

logical* 1 RE S WITCH 

logical* 1 TDLRSTATE) 1 :4) 

logical* 1 TDLRSTATUS) 1 :4) 

logical* 1 TDSSTATUS 

real*8 TEINTEGRAL 

real*8 TELIMIT 

real*8 THETA 

logical* 1 TS_STATUS( 1 :2) 

real*8 VELOCITYERROR 

real*8 YEINTEGRAL 

of module (jU 113 AN CE STT^VTE/ FO^R. 
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* Module: PLUTO.FOR 

* Facility: Pluto 

* P-Spec: 0 

* Abstract: 

* This module contains the main routine for the Pluto 

* implementation. 

* 

* List of Routines: 

* program Pluto 

* Title: PLUTO 

* Facility: Pluto 

* Abstract: 

* This is the main routine for the Pluto implementation. 

* 

* Arguments: None 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

* v2 15-Feb-1995 Philip Morris (PEM) 

program PLUTO 
implicit none 

*** include the global common stores *** 
include 'guidance state.for' 

*** execution begins here *** 

* Simply loop through the three subframes until done 

* v2 Changes for AR#26. Item 2. Remove dead code. 

*** 

*100 continue 
*** 

* v2 Changes for AR#26. End Change. 

* vl Changes for AR#23. Item 6&7. Added DO WHILE loop to remove gotos 
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*** stop when gp_phase = 5 *** 
do while (GPPHASE .NE. 5) 

*** execute the sensor processing subframe *** 
call SPSF 

*** execute the guidance processing subframe *** 
call GPSF 

*** execute the control law processing subframe *** 
call CLPSF 
end do 


* vl Changes for AR#23. End Change. 

stop 

end 

end of module P T < 1 1' I 
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* Module: RECLP.FOR 

* Facility: Pluto 

* P-Spec: 3.4 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for RECLP. 

* 

* List of Routines: 

* subroutine RECLP 

* Title: RECLP 

* Facility: Pluto 

* Abstract: 

* 1) determine the current operational status of the roll engines. 

* 2) generate the appropriate roll engine command. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

subroutine RECLP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensor_output.for' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

* 1) Determine the current operational status of the roll engines. 

RESTATUS = KSHEALTHY 

* 2) Generate the appropriate roll engine command. 

if (RE SWITCH .EQ. K$ROLL_EN GIN E S ARE OFF) then 
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RECMD = K$OFF + K$CW 
else 

*** range check the x-axis vehicle rotation rate *** 

call RANGE_CHECK(G_ROTATION(l , 0), K$G_ROT AT ION $LB , 

& K$G_ROTATION$UB, 'RECLP', K$G_ROTATION$NAME) 

*** range check the x-axis vehicle rotation displacement *** 

call RANGE_CHECK(THETA, K$THETA$LB, 

& K$THETA$UB, 'RECLP', K$THETA$NAME) 

* The roll engine command consists of two components: an 

* intensity, and a direction. Taking into account the command data 

* encoding, the possible intensities are: Off (0), Minimum (2), 

* Intermediate (4), and Maximum (6), and the possible directions 

* are Counterclockwise (0) and Clockwise (1). 

* 

* Both roll engine command components are determined from the 

* current value of the vehicle's roll rate and rotational 

* displacement about the x-axis. 

* 

* Employing Euler's method for differential equations, compute the 

* current x-axis angular displacement, theta. 

THETA = THETA + G_ROTATION(l, 0) * DELTA T 

*** range check the theta again before use *** 

call RAN GE_CHECK(THETA, K$THETA$LB, 

& K$THETA$UB, 'RECLP', K$THETA$NAME) 

* From figure 5.2 "Graph for Deriving Roll Engine Commands" of the 

* GCS development specifications, determine the appropriate roll 

* engine intensity and direction. 


*** check case when theta = 0 *** 

if (THETA .EQ. 0) then 
if (G_ROTAT10N(l, 0) .GT. P4) then 
RECMD = K$MAX1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .LT. -P4) then 
RECMD = K$MAX1MUM + K$CCW 
else 

RECMD = K$OFF + K$CW 
end if 
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*** check first and fourth quadrants *** 




* 


else if (THETA .GT. 0) then 
if (THETA .LE. THETA 1) then 

if (G_ROTATION(l, 0) .GT. P2) then 
RECMD = K$MAX1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .GT. PI) then 
RECMD = K$1NTERMEDIATE + K$CW 
else if (G_R0TAT10N(1, 0) .GE. -P4) then 
RECMD = K$OFF + K$CW 
else 

RECMD = K$MAX1MUM + K$CCW 
end if 

else if (THETA .LE. THETA2) then 

if (G_R0TAT10N(1, 0) .GT. P2) then 
RECMD = K$MAX1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .GT. PI) then 
RECMD = K$1NTERMED1ATE + K$CW 
else if (G_ROTATION(l, 0) .GT. 0.0) then 
RECMD = K$M1N1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .GE. -P4) then 
RECMD = K$OFF + K$CW 
else 

RECMD = K$MAX1MUM + K$CCW 
end if 


else 

THETA > THETA2 

if (G_R0TAT10N(1, 0) .GT. -P3) then 
RECMD = K$MAX1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .GE. -P4) then 
RECMD = K$OFF + K$CW 
else 

RECMD = K$MAX1MUM + K$CCW 
end if 


end if 


check second and third quadrants *** 


else 


THETA .LT. 0 

if (THETA .GE. -THETA1) then 


if (G_ROTATION(l, 0) .GT. p4) then 
RE CMD = K$MAXIMUM + K$CW 
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else if (G_ROTATION(l, 0) .GE. -PI) then 
RECMD = K$OFF + K$CW 
else if (G_R0TAT10N(1, 0) .GE. -P2) then 
RECMD = K$1NTERMED1ATE + K$CCW 
else 

RECMD = K$MAX1MUM + K$CCW 

end if 


else if (THETA .GE. -THETA2) then 

if (G_ROTATION(l, 0) .GT. P4) then 
RECMD = K$MAX1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .GE. 0.0) then 
RECMD = K$OFF + K$CW 

else if (G_R0TAT10N(1, 0) .GE. -PI) then 
RECMD = K$M1N1MUM + K$CCW 
else if (G_R0TAT10N(1, 0) .GE. -P2) then 
RECMD = KS1NTERMED1ATE + K$CCW 
else 

RECMD = K$MAX1MUM + K$CCW 
end if 


else 

THETA < -THETA2 

if (G_ROTATION(l, 0) .GT. P4) then 
RECMD = K$MAX1MUM + K$CW 
else if (G_R0TAT10N(1, 0) .GE. P3) then 
RECMD = K$OFF + K$CW 
else 

RECMD = K$MAX1MUM + K$CCW 

end if 


end if 
end if 
end if 


return 

end 

of module R F I p P0^ 
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* Module: RUNPARAMETERS.FOR 

* Facility: Pluto 

* Abstract: 

* This module contains the data definitions for the 

* global common data store named RUNPARAMETERS. 


* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 


*** COMMON block definition *** 

COMMON /RUNPARAMETERS/ 


& 

A BIAS, 

& 

A GAIN 0, 

& 

A SCALE, 

& 

ALPHA MATRIX, 

& 

AR FREQUENCY, 

& 

COMM SYNC PATTERN, 

& 

CONTOUR ALTITUDE, 

& 

CONTOUR VELOCITY, 

& 

DELTA T, 

& 

DROP HEIGHT, 

& 

DROP SPEED, 

& 

ENGINES ON ALTITUDE, 

& 

FULL UP TIME, 

& 

Gl, 

& 

G2, 

& 

G3, 

& 

G4, 

& 

G GAIN 0, 

& 

G OFFSET, 

& 

GA, 

& 

GAX, 

& 

GP1, 

& 

GP2, 

& 

GPY, 

& 

GQ, 

& 

GR, 

& 

GRAVITY, 

& 

GV, 

& 

GVE, 

& 

GVEI, 

& 

GVI, 

& 

GW, 

& 

GWI, 

& 

Ml, 

& 

M2, 

& 

M3, 

& 

M4, 
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*** 


MAXNORMALVELOCITY, 

OMEGA, 

PI, 

P2, 

P3, 

P4, 

PEMAX, 

PE_MIN, 

Tl, 

T2, 

T3, 

T4, 

TDLRANGLES, 

TDLRGAIN, 

TDLRLOCKTIME, 

TDLROFFSET, 

TEDROP, 

TEINIT, 

TEMAX, 

TE_MIN, 

THETA 1, 

THETA2, 

YEMAX, 

YE MIN 


data type declarations *** 


real*8 A_BIAS(1:3) 

real*8 A_GAIN_0(1:3) 

integer 515 4 A SCALE 

real*8 ALPHA_MATRIX(1:3, 1:3) 

real*8 ARFREQUENCY 

integer*2 COMM SYNC PATTERN 

real*8 CONTOUR_ALTITUDE(1:100) 

real*8 CONTOUR_VELOCITY( 1:100) 

real*8 DELTAT 

real*8 DROPHEIGHT 

real*8 DROPSPEED 

real*8 ENGINESONALTITUDE 

real*8 FULLUPTIME 

real*8 G1 

real*8 G2 

real*8 G3 

real*8 G4 

real*8 G_GAIN_0(1:3) 

real*8 G_OFFSET(l:3) 

real*8 GA 

real*8 GAX 

real*8 GP1 

real*8 GP2 

real*8 GPY 
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real*8 

GQ(1:2) 

real*8 

GR(1:2) 

real*8 

GRAVITY 

real*8 

GV(1:2) 

real*8 

GVE 

real*8 

GVEI( 1 :2) 

real*8 

GVI(1:2) 

real*8 

GW(1:2) 

real*8 

GWI(1:2) 

integer 515 2 

Ml 

integer*2 

M2 

integer*2 

M3 

integer 515 2 

M4 

real*8 

MAX NORMAL VELOCITY 

real*8 

OMEGA 

real*8 

PI 

real*8 

P2 

real*8 

P3 

real*8 

P4 

real*8 

PE MAX(1:2) 

real*8 

PE MIN(1:2) 

real*8 

T1 

real*8 

T2 

real*8 

T3 

real*8 

T4 

real*8 

TDLR ANGLES(1:3) 

real*8 

TDLR GAIN 

real*8 

TDLR LOCK TIME 

real*8 

TDLR OFFSET 

real*8 

TE DROP 

real*8 

TE IN IT 

real*8 

TE MAX( 1 :2) 

real*8 

TE MIN(1:2) 

real*8 

THETA 1 

real*8 

THETA2 

real*8 

YE MAX(1:2) 

real*8 

YE MIN(1:2) 


of module P ARA.MET ERS FOR. 
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* Module: SENSOROUTPUT.FOR 

* Facility: Pluto 

* Abstract: 

* This module contains the data definitions for the 

* global common data store named EXTERNAL. 


* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 


*** COMMON block definition *** 


COMMON /SENSOROUTPUT/ 

& AACCELERATION, 

& ARALT1TUDE, 

& ATMOSPHERICTEMP, 

& GROTATION, 

& TDSENSED, 

& TDLR VELOCITY 


*** data type declarations *** 

real* 8 A_ ACCELERATION) 1:3, 0:4) 

real* 8 AR_ALT1TUDE(0:4) 

real* 8 ATMOSPHERICTEMP 

real* 8 G_ROTATION(l:3, 0:4) 

logical* 1 TDSENSED 
real* 8 TDLR_VELOCITY(l:3, 0:4) 

of module SENSOR OE^TTPEIT FOR. 
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* Module: SPSF.FOR 

* Facility: Pluto 

* Abstract: 

* This module contains the entry for the sensor processing 

* subframe. 

* 

* List of Routines: 

* subroutine SPSF 

* Title: SPSF 

* Facility: Pluto 

* Abstract: 

* This routine provides control of the Sensor Processing SubFrame 

* processing. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

subroutine SPSF 
implicit none 

*** execution begins here *** 

call GC S S1M REN DEZ V OUS 

call TSP 

call ARSP 

call ASP 

call GSP 

call TDLRSP 

call TDSP 

call CP 

return 

end 

***** of module SPSF F'OI^ ******************************************** 
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* Module: TDLRSP.FOR 

* Facility: Pluto 

* P-Spec: 1.5 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for TDLRSP. 

* 

* List of Routines: 

* subroutine TDLRSP 

* Title: TDLRSP 

* Facility: Pluto 

* Abstract: 

* 1 ) Maintain the history of the vehicle velocities and the 

* velocity computation indicator 

* 2) Determine the operational status of touch down landing radar 

* sensor 

* 3) Report the current vehicle velocities along each of the 

* vehicle's three axes 

* 4) Report the velocity computation indicators. 

* 

* Arguments: None 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

* v2 10-JAN-1995 Philip Morris (PEM) 

subroutine TDLRSP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutput.for' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

*** declare local variables *** 

integer*4 i 

real*8 b(4) 
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real*8 

pbvX 

real*8 

pbvY 

real*8 

pbvZ 

real*8 

elapsedtime 


* 1 ) Maintain the history of the vehicle velocities and the 

* velocity computation indicator by "rotating variables." The data 


TDLRVELOCITY ( 1 , 4) 
TDLRVELOCITY ( 1 , 3) 
TDLRVELOCITY ( 1 , 2) 
TDLRVELOCITY ( 1 , 1) 

TDLRVELOCITY (2, 4) 
TDLRVELOCITY (2, 3) 
TDLRVELOCITY (2, 2) 
TDLRVELOCITY (2, 1) 

TDLRVELOCITY (3, 4) 
TDLR_VELOCITY(3, 3) 
TDLR VELOCITY (3, 2) 
TDLR_VEL0C1TY(3, 1) 


= TDLRVELOCIT Y ( 1 , 3) 
= TDLR VELOCIT Y ( 1 , 2) 
= TDLR_VEL0C1TY(1, 1) 
= TDLR VELOCIT Y ( 1 , 0) 

= TDLR VELOCITY (2, 3) 
= TDLR VELOCITY (2, 2) 
= TDLRVELOCITY (2, 1) 
= TDLR VELOCITY (2, 0) 

= TDLR_VEL0C1TY(3, 3) 
= TDLR_VEL0C1TY(3, 2) 
= TDLR_VEL0C1TY(3, 1) 
= TDLR_VEL0C1TY(3, 0) 


K_MATRIX(1, 1, 4) 
K_MATRIX(1, 2, 4) 
K_MATRIX(1, 3, 4) 
K_MATRIX(2, 1, 4) 
K_MATRIX(2, 2, 4) 
K_MATRIX(2, 3, 4) 
K_MATRIX(3, 1, 4) 
K_MATRIX(3, 2, 4) 
K_MATRIX(3, 3, 4) 

K_MATRIX(1, 1,3) 
K_MATRIX(1, 2, 3) 
K_MATRIX(1, 3, 3) 
K_MATRIX(2, 1,3) 
K_MATRDC(2, 2, 3) 
K_MATR1X(2, 3, 3) 
K_MATR1X(3, 1,3) 
K_MATRDC(3, 2, 3) 
K_MATR1X(3, 3, 3) 

K_MATR1X(1, 1, 2) 
K_MATR1X(1, 2, 2) 
K_MATR1X(1, 3, 2) 
K_MATR1X(2, 1, 2) 
K_MATRDC(2, 2, 2) 


= K_MATR1X( 1 , 1, 3) 
= K_MATR1X( 1 , 2, 3) 
= K_MATR1X( 1 , 3, 3) 
= K_MATR1X(2, 1, 3) 
= K_MATR1X(2, 2, 3) 
= K_MATR1X(2, 3, 3) 
= K_MATR1X(3, 1, 3) 
= K_MATR1X(3, 2, 3) 
= K_MATR1X(3, 3, 3) 

= K_MATR1X( 1 , 1,2) 
= K_MATR1X( 1 , 2, 2) 
= K_MATR1X( 1 , 3, 2) 
= K_MATR1X(2, 1, 2) 
= K_MATR1X(2, 2, 2) 
= K_MATR1X(2, 3, 2) 
= K_MATR1X(3, 1, 2) 
= K_MATR1X(3, 2, 2) 
= K_MATR1X(3, 3, 2) 

= K_MATR1X( 1 , 1, 1) 
= K_MATR1X( 1 , 2, 1) 
= K_MATR1X( 1 , 3, 1) 
= K_MATR1X(2, 1,1) 
= K_MATR1X(2, 2, 1) 


C-79 



K_MATRIX(2, 3, 2) 
K_MATRIX(3, 1, 2) 
K_MATRIX(3, 2, 2) 
K_MATRIX(3, 3, 2) 

K_MATRIX(1, 1, 1) 
K_MATRIX(1, 2, 1) 
K_MATRIX(1, 3, 1) 
K_MATRIX(2, 1, 1) 
K_MATRIX(2, 2, 1) 
K_MATRIX(2, 3, 1) 
K_MATRIX(3, 1, 1) 
K_MATRIX(3, 2, 1) 
K_MATRIX(3, 3, 1) 


= K_MATRIX(2, 3, 1) 
= K_MATRIX(3, 1,1) 
= K_MATRIX(3, 2, 1) 
= K_MATR1X(3, 3, 1) 

= K_MATR1X( 1 , 1, 0) 
= K_MATR1X( 1 , 2, 0) 
= K_MATR1X( 1 , 3, 0) 
= K_MATRIX(2, 1, 0) 
= K_MATRIX(2, 2, 0) 
= K_MATRIX(2, 3, 0) 
= K_MATRIX(3, 1, 0) 
= K_MATRIX(3, 2, 0) 
= K_MATRIX(3, 3, 0) 


* 2) Determine the operational status of touch down landing radar sensor. 


TDLRSTATUS(l) = K$HEALTHY 
TDLR_STATUS(2) = K$HEALTHY 
TDLR_STATUS(3) = K$HEALTHY 
TDLRSTATU S(4) = K$HEALTHY 

* 3) Reporting the current vehicle velocities along each of the 

* vehicle's three axes and reporting the velocity computation 

* indicators. 


* 3A) Determine the state of the four radar beams. 

* 

* The data element TDLR STATE contains the state of the radar 

* beams. 

* 

* Valid radar beam states are "locked" (value 1) and "unlocked" 

* (value 0). The present state of a radar beam is determined from 

* the current value of the sensor data and the previous state of 

* the radar beam. A sensor measurement of zero indicates that the 

* radar beam echo was not received and the radar beam is considered 

* to be "unlocked." A non-zero sensor measurement indicates that a 

* radar beam echo was received, but does not imply a radar beam 

* state of "locked." Because, once a radar beam is declared 

* "unlocked," it is rendered unusable (remains "unlocked" 

* regardless of the sensor data value) for a specified period of 

* time. This waiting period must be implemented in the software. 

* 

* A beam is deemed "locked" when 1 ) the current sensor value 

* contains a non-zero value and the beam's previous state was 

* "locked"; or 2) the current sensor value contains a non-zero 
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* value and the beam's previous state was "unlocked" and the 

* elapsed time since the beam was determined "unlocked" is greater 

* than or equal to the sensor recovery period. 

* 

* The data element TDLRLOCKTIME specifies the unlocked sensor 

* recovery (waiting) period. The data element FRAMEBEAMUNLOCKED 

* is updated with the value of the FRAMECOUNTER during the frame 

* in which a radar beam state is first determined as "unlocked." 

* The data element DELTAT specifies in seconds the duration of a 

* single frame. Thus the elapsed time since a radar beam was 

* declared "unlocked" can be determined by subtracting the present 

* value of FRAME COUNTER from the value of FRAME BEAM UNLOCKED and 

* multipling the result by the value of DELTA T. 

**** p rocess each radar beam *** 
do 100 i=l,4 

if (TDLR COUNTER(i) .EQ. 0) then 

if (TDLR STATE(i) .EQ. K$BEAM_LOCKED) then 
TDLRSTATE(i) = K$BEAM_UNLOCKED 

FRAMEBEAMUNLOCKED(i) = FRAMECOUNTER 


* v2 Changes for AR#24. Item 7. Added else if. 

* else 

elseif (TDLR STATE(i) .EQ. K$BEAM_UNLOCKED) then 

* v2 Changes for AR#24. End Change. 

* the beam was unlocked 
elapsedtime = DELTA T * 

& (FRAME COUNTER - FRAME_BEAM_UNLOCKED(i)) 

if (elapsed time .GE. TDLRLOCKTIME) then 
FRAMEBEAMUNLOCKED(i) = FRAMECOUNTER 
end if 
end if 

else 

* the sensor measurement != 0 

if (TDLR STATE(i) .EQ. K$BEAM_UNLOCKED) then 
elapsed time = DELTA T * 

& (FRAME COUNTER - FRAME BEAM UNLOCKED(i)) 

if (elapsed time .GE. TDLR LOCK TIME) then 
TDLRSTATE(i) = K$BEAM_LOCKED 
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end if 
end if 
end if 

100 continue 

* 3B) Determine the beam velocities. 

do 200 i=l,4 

b(i) = TDLROFFSET + TDLRGA1N * TDLRCOUNTER(i) 

200 continue 

* 3C) Determine the "processed" beam velocities, and 

* 4) Determine the velocity computation indicators. 

* Compute a "processed" beam velocity for each of the three axes as 

* specified by the following table: 

* 

* Beams | PROCESSED BEAM VELOCITIES | K-MATR1X | Case 

* in lock | pbvX pbvY pbvZ X Y Z | Number 


* 

none 

o 

0 

o 

1 o | 

0 

0| 0 


* 

1 

0 

0 

o 

1 0 1 0 

|0 

1 


* 

2 I 

0 

0 

0 

1 0 1 0 

|0 

2 


* 

3 1 

0 

1 0 

1 0 

1 0 1 0 

|0 

1 4 


* 

* 

4 

0 

0 

1 

0 

1 

1 0 1 0 

|0 

8 


* 

— 

1,2 

0 

(b(l)-b(2))/2 

0 1 

0 

1 1 0 1 

3 

* 

1,3 

(b(l)+b(3))/2 

0 

0 

1 

0 1 0 

5 

* 

1,4 

0 

o 

| (b(l)-b(4))/2 I 

0 

0 1 1 1 

9 

* 

2,3 

0 

0 

| (b(2)-b(3))/2 | 

0 

0:1.1 | 

6 

* 

2,4 

(b(2)+b(4))/2 

o 1 

0 

1 

0 1 0 

10 

* 

3,4 

0 

(b(4)-b(3))/2 

0 1 

0 

1 1 0 1 

12 


* 1,2,3 | (b(l)+b(3))/2 | (b(l)-b(2))/2 | (b(2)-b(3))/2 | 1 | 1 | 1 | 7 

* 1,2,4 | (b(2)+b(4))/2 | (b(l)-b(2))/2 | (b(l)-b(4))/2 | 1 | 1 | 1 | 11 

* 1,3,4 | (b(l)+b(3))/2 | (b(4)-b(3))/2 | (b(l)-b(4))/2 | 1 | 1 | 1 | 13 

* 2,3,4 | (b(2)+b(4))/2 | (b(4)-b(3))/2 | (b(2)-b(3))/2 | 1 | 1 | 1 | 14 


* 1,2, 3, 4 | a | b | c | 1 | 1 | 1 | 15 

* 

* a) (b(l)+b(2)+b(3)+b(4))/4 

* b) (b(l)-b(2)-b(3)+b(4))/4 

* c) (b(l)+b(2)-b(3)-b(4))/4 

* 

* Each of the 1 6 possible cases has been assigned a case number to 

* facilitate the description of the necessary processing. The case 

* number is found in the column labled "Case Number" in the table 
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* above. 

* 

* Determine the case number value for the current processing. 

* Each of the four radar beams' state has been assigned a weight 

* value: beam 1:1, beam 2: 2, beam 3: 4, beam 4: 8. The "case 

* number" is computed by summing the radar beams multiplied by their 

* their weight factors. 


* vl Changes for AR#23. Item 24. Default goto 2000 added. 


go to ( 1 000, 1 000, 1 000, 1010,1 000, 1 020, 1 040, 1 070, 

& 1000,1030,1050,1080,1060,1090,1 100,1 1 10), 

& TDLR_STATE( 1 ) + 2*TDLR_STATE(2) + 

& 4*TDLR_STATE(3) + 8*TDLR_STATE(4) + 1 
go to 2000 

* vl Changes for AR#23. End Change. 

*** 

*** cases 0, 1, 2, 4, 8 *** 


1000 pbvX = 0.0 
pbvY = 0.0 
pbvZ = 0.0 


K_MATR1X(1, 1, 0) = 0 
K_MATR1X(2, 2, 0) = 0 
K_MATR1X(3, 3, 0) = 0 
go to 2000 

1010 pbvX = 0.0 

pbvY = (b(l) - b(2)) / 2.0 
pbvZ = 0.0 


K_MATR1X(1, 1, 0) = 0 
K_MATR1X(2, 2, 0) = 1 
K_MATR1X(3, 3, 0) = 0 
go to 2000 

CctSG 5 


1020 pbvX = (b(l) + b(3))/ 2.0 
pbvY = 0.0 
pbvZ = 0.0 


K_MATR1X( 1 , 1, 0) = 1 
K_MATR1X(2, 2, 0) = 0 
K_MATR1X(3, 3, 0) = 0 
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go to 2000 


CctSG 9 

1030 pbvX = 0.0 
pbvY = 0.0 

pbvZ = (b(l) - b(4)) / 2.0 

K_MATR1X(1, 1, 0) = 0 
K_MATR1X(2, 2, 0) = 0 
K_MATR1X(3, 3, 0) = 1 
go to 2000 

*** case 6 *** 

* vl Changes for AR#23. Item 25. Goto 2000 added to finish the case properly 

1040 pbvX = 0.0 
pbvY = 0.0 

pbvZ = (b(2) - b(3)) / 2.0 

K_MATR1X(1, 1, 0) = 0 
K_MATR1X(2, 2, 0) = 0 
K_MATR1X(3, 3, 0) = 1 
go to 2000 

* vl Changes for AR#23. End Change. 

*** case 10 *** 

1050 pbvX = (b(2) + b(4)) / 2.0 
pbvY = 0.0 
pbvZ = 0.0 

K_MATR1X(1, 1, 0) = 1 
K_MATR1X(2, 2, 0) = 0 
K_MATR1X(3, 3, 0) = 0 
go to 2000 

C3.SC 12 

1060 pbvX = 0.0 

pbvY = (b(4) - b(3)) / 2.0 
pbvZ = 0.0 

K_MATR1X(1, 1, 0) = 0 
K_MATR1X(2, 2, 0) = 1 
K_MATR1X(3, 3, 0) = 0 
go to 2000 
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h* h* y 


1070 pbvX = (b( 1) + b(3)) / 2.0 
pbvY = (b( 1) - b(2)) / 2.0 
pbvZ = (b(2) - b(3)) / 2.0 

K_MATRIX(1, 1, 0) = 1 
K_MATR1X(2, 2, 0) = 1 
K_MATR1X(3, 3, 0) = 1 
go to 2000 

CctSG 11 

1080 pbvX = (b(2) + b(4)) / 2.0 
pbvY = (b( 1) - b(2)) / 2.0 
pbvZ = (b ( 1 ) - b(4)) / 2.0 

K_MATR1X(1, 1, 0) = 1 
K_MATR1X(2, 2, 0) = 1 
K_MATR1X(3, 3, 0) = 1 
go to 2000 


CctSG 13 

1090 pbvX = (b(l) + b(3))/ 2.0 
pbvY = (b(4) - b(3)) / 2.0 
pbvZ = (b(l)-b(4))/ 2.0 

K_MATRIX(1, 1, 0) = 1 
K_MATR1X(2, 2, 0) = 1 
K_MATR1X(3, 3, 0) = 1 
go to 2000 

^ H® 14 

1100 pbvX = (b(2) + b(4)) / 2.0 
pbvY = (b(4) - b(3)) / 2.0 
pbvZ = (b(2) - b(3)) / 2.0 

K_MATRIX(1, 1, 0) = 1 
K_MATR1X(2, 2, 0) = 1 
K_MATRIX(3, 3, 0) = 1 
go to 2000 

CctSG 15 

1110 pbvX = (b( 1) + b(2) + b(3) + b(4)) / 4.0 
pbvY = (b( 1) - b(2) - b(3) + b(4)) / 4.0 
pbvZ = (b(l) + b(2) - b(3) - b(4)) / 4.0 

K_MATR1X(1, 1, 0) = 1 
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K_MATR1X(2, 2, 0) = 1 
K_MATR1X(3, 3, 0) = 1 

2000 continue 

* 3D) Convert "processed" beam velocities into body velocites. 


TDLRVELOCITY ( 1 , 0) = pbvX / COS(TDLR_ANGLES(l)) 
TDLRVELOCITY (2, 0) = pbvY / COS(TDLR_ANGLES(2)) 
TDLR_VELOClTY(3, 0) = pbvZ / COS(TDLR_ANGLES(3)) 


return 

end 


***** end of module tdlrsp.for 
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* Module: TDSP.FOR 

* Facility: Pluto 

* P-Spec: 1.6 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for C-RCP. 

* 

* List of Routines: 

* subroutine TDSP 

* Title: TDSP 

* Facility: Pluto 

* Abstract: 

* 1 ) Determine the operational status of the touch down sensor 

* 2) determine if touch down has been sensed. 

* 

* Arguments: None 

* 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

subroutine TDSP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutputfor' 

*** include constant definitions *** 

include 'constants. for' 

* 1 ) Determine the operational status of the touch down sensor. 

* 2) determine if touch down has been sensed. 

* 

* The data element TDCOUNTER represents the sensor's measurement. 

* There are only two valid sensor measurements: A) all bits set 

* (value -1) which indicates touch down is sensed, and B) all bits 

* clear (value 0) which indicates touch down is not sensed. If a valid 

* sensor value exists, then the operation status of the touch down sensor 

* is reported as "healthy" (value 0). Any other value of TD COUNTER 

* indicates a faulty sensor in which case the touch down sensor 

* status is reported as "failed" (value 1 ). 
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* 

* Note, once the touch down sensor has been determined to be 

* faulty, it is considered to be failed for the duration of the 

* mission — no processing occurs once the sensor has failed. 


if (TDS STATUS .EQ. K$HEALTHY) then 

if (TDCOUNTER .EQ. 0) then 
TDSENSED = K$TOUCH_DOWN_NOT_SENSED 


* 


else if (TD COUNTER .EQ. -1) then 
TDSENSED = K$TOUCH_DOWN_SENSED 

faulty sensor 


else 

TDSENSED = K$TOUCH_DOWN_NOT_SENSED 
TDS STATUS = KSFAILED 


end if 


end if 


return 

end 

GTld of module TCDS-P 
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* Module: TSP.FOR 

* Facility: Pluto 

* P-Spec: 1.7 

* Abstract: 

* This module contains the implementation of the functional 

* requirements for TSP. 

* 

* List of Routines: 

* subroutine TSP 

* function LO WERP ARAB OL1C F UN CTION 

* function UPPERPARABOLICFUNCTION 

* Title: TSP 

* Facility: Pluto 

* Abstract: 

* 

* Purpose: 

* 1) Ascertain the operational status of the temperature sensors. 

* 2) Determine the current atmospheric temperature based on the 

* measurements provided by two on-board temperature sensors. 

* 

* Arguments: None 

* Revision Flistory: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

* v2 10-JAN-1995 Philip Morris (PEM) 

subroutine TSP 
implicit none 

*** include the global common stores *** 

include 'extemal.for' 
include 'guidancestate.for' 
include 'sensoroutput.for' 
include 'run_parameters.for' 

*** include constant definitions *** 

include 'constants. for' 

*** declare local functions *** 

real*8 LOWERPARABOLICFUNCTION 

real*8 UPPER PARABOLIC FUNCTION 
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*** declare local variables *** 


real*8 slope 
real*8 solidstatetemp 
real*8 lower_parabolic_temp_limit 
real*8 upper_parabolic_temp_limit 
real* 8 para_M2_Ml 
real* 8 REALTHERMOTEMP 

* 1 ) Determine the operational status of the temperature sensors 

TSSTATUS(l) = K$HEALTHY 
TS_STATUS(2) = K$HEALTHY 

* 2A) Compute the temperature based on the solid state sensor 


* vl Changes for AR#23. Item 26. Added variable to cast M2-M1 to a real 

para_M2_Ml = M2-ml 
call ZERO_CHECK(para_M2_M 1 , 'TSP') 


* vl Changes for AR#23. End Change. 

slope = (T2 - T1)/(M2 - Ml) 

solid state temp = slope * SS TEMP + T1 - slope * Ml 

* 2B) Determine if the temperature is within the valid range of the 

* TC sensor; 

* Once the function describing the parabola has been determined, the 

* temperature representing the lower limit of the parabolic region can 

* be determined. The lower limit of the lower parabolic region is 

* specified as 15% of the difference of the two calibration 

* measurements less than the lower calibration point. 


* vl Changes for AR#23. Item 2. "DO" added to 0.15 
lower_parabolic_temp_limit = 

& L0WER_PARAB0L1C_FUNCT10N(M3 - 0. 1 5D0*(M4 - M3)) 
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* vl Changes for AR#23. End Change. 

*** 

* Once the function describing the parabola has been determined, the 

* temperature representing the upper limit of the parabolic region can 

* be determined. The upper limit of the upper parabolic region is 

* specified as 15% of the difference of the two calibration 

* measurements greater than the upper calibration point. 


* vl Changes for AR#23. Item 2. "DO" added to 0.15 

upper_parabolic_temp_limit = 

& UPPERP ARAB OLICFUN CTION ( M4 + 0. 1 5D0*(M4 - M3)) 

* vl Changes for AR#23. End Change. 

*** 

* Now determine sensor temperature measurement to report 


if ((solidstatetemp .LT. lower_parabolic_temp_limit) .OR. 

& (solid state temp .GT. upper_parabolic_temp_limit)) then 

*** the atmospheric temp is beyond the valid range of the TC sensor *** 
*** so return the solid state temp *** 


ATMOSPHERICTEMP = solidstatetemp 
else 

* 2C) Compute the temperature based on the TC sensor 
if (THERMO TEMP .LT. M3) then 


*** the atmospheric temp resides within the TC lower parabolic region *** 
* v2 Changes for AR#24. Item 6. Added variable to cast to a real 


RE ALTHERMOT EMP=THERMO_T EMP 
ATMOSPHERICTEMP = 

LOW ERPARAB OLICF UN CTION (RE ALTHERMOT EMP ) 

* ATMOSPHERICTEMP = LOWER_PARABOLIC_FUNCTION(THERMO_TEMP) 
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else if (THERMO TEMP .GT. M4) then 


*** the atmospheric temp resides within the TC upper parabolic region *** 

RE AL_THERMO_TEMP=THERMO_T EMP 
ATMOSPHERICTEMP = 

UPPER_PARABOLIC_FUNCTION(REAL_THERMO_TEMP) 

* ATMOSPHERICTEMP = UPPERPARAB OLICFUN CTION (THERMOT EMP ) 
*** 

* v2 Changes for AR#24. End Change. 

*** 


else 

*** The temperature resides within the TC sensor linear region *** 
*** compute the temperature from the TC linear region *** 

slope = (T4 - T3)/(M4 - M3) 

ATMOSPHERICTEMP = 

& slope * THERMO TEMP + T3 - slope * M3 

end if 
end if 

return 

end 

***** q jp subroutine 1 S 

* Title: LOWER PARABOLIC FUNCTION 

* Facility: Pluto 

* Abstract: 

* This routine represents the function of the lower parabolic 

* curve of the TC temperature sensor. Given an ’X’ value, 

* return the corresponding 'Y 1 value. 

* 

* Arguments: 

* real* 8 x — the 'X' value of interest 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

real*8 function LOWER_PARABOLlC_FUNCTION(x) 


implicit none 

*** define the arguments *** 
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real*8 x 


*** include the global common stores *** 
include 'run_parameters.for' 

*** local variables *** 
real*8 halfslope 
*** execution begins here *** 

half slope = ((T4 - T3)/(M4 - M3)) / 2.0 

* vl Changes for AR#23. Item 27. "M3 + half' changed "M3 - half' 

LOW ERPARAB OL1CFUN CT ION = 

& -(x - M3 - half_slope)**2 + T3 + half_slope**2 

*** 

* vl Changes for AR#23. End Change. 

return 

end 

***** end of function LOWERPARABOLICFUNCTION ************************** 

* Title: UPPER PARABOLIC FUNCTION 

* Facility: Pluto 

* Abstract: 

* This routine represents the function of the upper parabolic 

* curve of the TC temperature sensor. Given an 'X' value, 

* return the corresponding 'Y' value. 

* 

* Arguments: 

* real* 8 x — the 'X' value of interest 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Originial. 

* vl 30-Nov-1994 Philip Morris (PEM) 

real*8 function UPPER_PARABOLlC_FUNCTION(x) 
implicit none 

*** define the arguments *** 
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real*8 x 


*** include the global common stores *** 
include 'run_parameters.for' 

*** local variables *** 
real*8 halfslope 
*** execution begins here *** 

half slope = ((T4 - T3)/(M4 - M3)) / 2.0 

*** 

* vl Changes for AR#23. Item 28. Algebra Problem fixed. 

*** 

UPPERPARABOLICFUNCTION = 

& (x - M4 + half_slope)**2 + T4 - half_slope**2 

*** 

* vl Changes for AR#23. End Change. 

*** 

return 

end 

***** of furiCtlOIT UPPER. PARABOLIC ************************** 

***** of module TSP PUR ********************************************* 
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* Module: UTILITY.FOR 

* Facility: Pluto 

* Abstract: 

* A collection of utility routines for Pluto. 

* 

* List of Routines: 

* subroutine RANGECHECK 

* subroutine NEG VALUE CHECK 

* subroutine ZERO CHECK 

* Title: RANGE CHECK 

* Facility: Pluto 

* Abstract: 

* Given a real*8 data element and it's lower and upper bounds, 

* determine if the data element exceeds the lower or upper 

* bound. If the element exceeds one of the bounds, then display 

* an error message. 

* 

* Arguments: 

* source real* 8 

* lowerbound real* 8 

* upperbound real* 8 

* module text character*(*) 

* variable text character*(*) 

* 

* Notes: 

* The upper bound >= lower bound 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

subroutine RANGE_CHECK(source, lower bound, upper bound, 
& module_text,variable_text) 


The value to check. 

The lower bound 

The upper bound 

The module name for error msg 

The data name for error msg 


implicit none 

*** define the subroutine arguments *** 


real*8 

real*8 

real*8 

character*(*) 

character*(*) 


source 

lowerbound 
upperbound 
moduletext 
variable text 


*** include a global common store *** 
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include 'extemal.for' 


*** format statements *** 

*** 

* vl Changes for AR#23. Item 29. "x" added before "14". 

1 0 format (x,'%EXCEPTION AL-CONDITION-GCS-LO WERLIMITEXCEEDED') 
20 format (x,'%EXCEPT 10NAL-C0NDIT10N-GCS-UPPER_L1M1T_EXCEEDED') 
30 format (x, A6, X, A32, x,14) 

40 format (x, A32, E23.14) 

*** 

* vl Changes for AR#23. End Change. 

*** execution begins here *** 

if (source .LT. lower bound) then 
write (6, 1 0) 

write (6, 30) moduletext, moduletext, FRAMECOUNTER 
write (6, 40) variable text, source 
else if (source .GT. upper bound) then 
write (6, 20) 

write (6, 30) module text, module text, FRAME COUNTER 
write (6, 40) variable text, source 
end if 

return 

end 

of RANGE C'tlEC'IC. 

* Title: NEG VALUE CHECK 

* Facility: Pluto 

* Abstract: 

* Given a real* 8 data element determine if the data element 

* has a value of less then zero. If the value is less than zero, 

* then display an error message. 

* 

* Arguments: 

* source real* 8 The value to check. 

* module text character*(*) The module name for error msg 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 

subroutine NEG_VALUE_CHECK(source, module text) 
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implicit none 

*** define the subroutine arguments *** 

real*8 source 

character*(*) moduletext 

*** include a global common store *** 

include 'extemal.for' 

*** format statements *** 

*** 

* vl Changes for AR#23. Item 29. "x" added before "14". 

*** 

1 0 format (' ','%EXCEPTIONAL-CONDITION-GCS-NEGATIVE_SQUARE_ROOT') 

30 format (x, A6, X, A32, x,14) 

40 format (x, E23 . 1 4) 

*** 

* vl Changes for AR#23. End Change. 

*** 

*** execution begins here *** 

if (source .LT. 0) then 
write (6, 1 0) 

write (6, 30) module text, module text, FRAME COUNTER 
write (6, 40) source 
end if 

return 

end 

of NEG /\ j ^ j p, ********************************************** 

* Title: ZERO CHECK 

* Facility: Pluto 

* Abstract: 

* Given a real* 8 data element determine if the data element 

* has a value of zero. If the value is zero, then display 

* an error message. 

* 

* Arguments: 

* source real* 8 The value to check. 

* module text character*(*) The module name for error msg 

* 

* Revision History: 

* vO 15-sep-1994 Rob Angellatta (RKA) Original. 

* vl 30-Nov-1994 Philip Morris (PEM) 
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subroutine ZERO_CHECK(source, moduletext) 
implicit none 

*** define the subroutine arguments *** 

real*8 source 

character*(*) moduletext 

*** include a global common store *** 

include 'extemal.for' 

*** format statements *** 


* vl Changes for AR#23. Item 29. "x" added before "14". 

10 format (x,'%EXCEPT 10NAL-C0NDIT10N-GCS-D1V1DE-BY-ZER0') 
30 format (x, A6, X, A32, x,14) 

*** 

* vl Changes for AR#23. End Change. 

*** execution begins here *** 

if (source .EQ. 0) then 
write (6, 1 0) 

write (6, 30) module text, module text, FRAME COUNTER 
end if 


return 

end 






of module T IT II /TT^^ FOR. 
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